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(57) ABSTRACT 

A mapper to translate an input file from an input domain to 
an output domain. The mapper includes a canons utility 
which builds a canon, the canon being a tree relating all data 
attributes within a domain of information, and the domain 
being a collection of data that has a same data format, a maps 
utility which creates input and output maps that specify the 
translation from the input domain to the output domain, and 
a translator utility to perform the translation of the input file 
to an output file. The input map is a data structure that 
describes a format of the input domain and the output map 
is a data structure that describes a format of the output 
domain. The input map and the output map are derivation 
trees, and the mapper utilizes the input map and the output 
map to build a scanner/parser for the input file domain. The 
mapper traverses the input map to parse data from the input 
file into a list. The mapper then maps from the list to the 
output domain to generate the output file by traversing the 
output map and reinterpreting a corresponding element in 
the list such that the corresponding element conforms to the 
output domain. 
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ScheduleBuilder 



plonForRange( ) 
notifyMeterChange( ) 
buildWorkPlan( ) 

CQlculateD ueTimeForReceiveSchedule( ) 

1 i r , 



r 1 

workPlans 



WorkPlan 



workPlanld:RWinteger 
startTime:RWTime 
endTime:RWTime 
curjobrint 



getNextJob( ) 
addJob( ) 
removeJob( ) 
getFirstJob( ) 
getCurrentJob( ) 



ScheduleMgr 



) 



createDeliverySchedule( ) 
deleteBillingSchedule( ) 

assignGroupToSchedule( ) 

dessignGroupFromSchedule 

createAvaitabilitySchedule( 1 

deleteAvailabilitySchedule( ) 

retrieveRcvSchedForGroup( ) 

getSchedulesForRange( ) 

findSupplierScheduleForAMRSchedule( ) 

createSupplierScheduleForAMRSchedule{ ) 

isScheduleEmpty( ) 
j 



JobSpan 



mustFinishBy:RWTime 
earliestStartRWTime 
latestStart:RWTime 
timespantRWInteger 



setTheSchedule( ) 




executePlan( ) 
executeNextJob( ) 
suspendPlan( ) 
addWorkPlan( ) 



ScheduldView 



schedulesForDote( } 
schedulesForRange( J 
addSchedule( ) 
remoYeSchedule( ) 



0.. 



T 



\ theSchedules 
\ ^dependents 

'0. 



dependsOn 




theJob 



Job 



Job!d:RWInteger 

earliestStart:RWTime 

latestStart:RWTime 



performjob( ) 
expectedEndTime( ) 
secondsTilStQriTime( ) 



1 



Alarm 




whatToDo 



1 



FIG. 23B 



scheduleEventld : long 
eventType : EventType; 
activityName : RWCString 
averogeTimeToExecute : RWInteger 



executeSchedule( ) 
subsumes( ) 
conflidsWith( ) 



04/16/2004, EAST Version: 1.4.1 



U.S. Patent Mar. 6, 2001 Sheet 32 of 46 US 6,199,068 Bl 



u 

CO 
CN 



[vent 






]dn<x 




lityGi 




labil 




o 




> 
< 






Q 
O 

r 

o 



in 
o 



to 

O 

E °* 
o 

z _ 

* a 

* § 

a> o 
.> iZ 
— a> 







c 




a> 




> 
Ul 




CL 








O 








o 




_a> 








o 








Q_ 




T3 




a 




o 




-J 









c 








> 




UJ 




c 




Bil 





04/16/2004, EAST Version: 1.4.1 



U.S. Patent 



Mar. 6, 2001 



Sheet 33 of 46 



US 6,199,068 Bl 



1 




ScheduleTask 



scheduleTaskld : long 
active : RWBoolean 
scheduleType : ScheduleType 



subsumes( ) 
conflictsWith( ) 
executeSchedule( ) 
nextTimeAfter( ) 
nextTimeAtOrAfter( ) 
nextTimeWithinExclusive( ) 
nextTimeWithininclusive( ) 
latestStartTimeFor( ) 
earliestStartTimeFon ) 
earliestDataTimeFor( ) 
baseTimeOfDay( ) 
trueForOate( ) 
trueForRange( ) 
receiveTimeCompatible( ) 
averageTimeToExecute( ) 



dependsO^^P 6 ^ 50 " 




dependents 



0.. 



\ 1 
what 



ScheduleTime 



scheduleTimeld : long 
scheduleTimeType : scheduleTimeType 

trueForDate( ) 
trueForRange( ) 
nextTimeAfter( ) 
nextTimeAtOrAfter( ) 
nextTimeWithinExclusive( ) 
nextTimeWithinlnclusive( ) 
secondsTIINextTime( ) 
latestStar1TimeFor( ) 
earliestStarfRmeForf ) 
earlIestDataTimeFor( ) 
baseTimeOfDay( ) 
is Repeatingf ) 
getTolerance( ) 
getType( ) 
typelsEqual( ) 
periodisCompatible( ) 




1 



ScheduleEvent 



scheduleEventld : long 
eventType : EventType; 
activityName : RWCString 
averageTimeToExecute : RWinteger 
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DISTRIBUTED SERVER TO TRANSLATE 
BETWEEN DISSIMILAR FILE FORMATS 

CROSS REFERENCE TO RELATED 
APPLICATIONS 

This application claims the benefit of U.S. Provisional 
Patent Application Ser. No. 60/058,659, to Kelley et ah, filed 
Sep. 11, 1997, entitled "AUTOMATIC METER READING 
SYSTEM". 

FIELD OF THE INVENTION 

The present invention relates generally to an automated 
meter reading (AMR) system, and more particularly to an 
AMR server within the automated reading system which 
collects, loads and manages data from energy meters, and 
processes and stores meter data for routing to end users and 
business systems. 

ACRONYMS AND KEYWORDS 

The written description provided herein contains acro- 
nyms and keywords to describe the various system compo- 
nents and services. Although known, use of several of the 
acronyms and keywords is not standardized in the art. For 
the purposes of the written description herein, acronyms and 
keywords are defined as follows: 
ACID — Atomicity, Consistency, Isolation, Durability 
AMPS — Analog Mobile Phone System 
AMR — Automated Meter Reading 
API — Application Program Interface 
BOM — Bill of Material 
C&I — Commercial and Industrial 
CIS — Customer Information System 
CDS — Cell Directory Service 
CDMA — Code Division Multiplexed Access 
CDPD— Cellular Digital Packet Data 
CM — Communications Manager 

CORBA — Common Object Request Broker Architecture 
CPU — Central Processing Unit 

CRUDLE— Create, Read, Update, Delete, List, and Exists 

CSR — Customer Service Representative 

CURDLE— Create, Update, Read, Delete, List and Exist 

DAO — Data Access Object 

DCE — Distributed Computing Environment 

DFS — Distributed File Service 

DSS — Distributed Security Service 

DTS — Distributed Time Service 

ESCO — Non-Grid and Non-Commodity Energy Services 

Companies 
ESP — Energy Service Provider 
GUI — Graphical User Interface 
IDL — Interface Definition Language 
ISO — Independent System Operator 
LAN — Local Area Network 

LECRUD— List, Exist, Create, Read, Update and Delete 

MDMA — Meter Data Management Agent 

OMS — Outage Management System 

OO — Object Oriented 

PM — Wholesale Power Market Services 

PSTN— Public Switched Telephone Network 

PX — Power Exchange 

RDBMS — Relational Database Management System 
RF — Radio Frequency 
RM — Resource Managers 
RPC— Remote Procedure Call 
RPU — Real Time Processor Unit 
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RQS — Recoverable Queuing System 

RSP — Remote Stored Procedure 

RTG — Remote Terminal Gateway 

RTU — Remote Telemetry Unit 
5 SC — Schedule Coordinator 

SCAD A — Supervisory Control and Data Acquisition 

SFS — Structured File System 

SNMP — Simple Network Management Protocol 

SOE — Sequence of Events 
1Q TDMA — Tune Division Multiple Access 

TM — Transaction Manager 

TOU— Time of Use 

UDC — Utility Distribution Company 

UPC — Universal Protocol Converter 

VEE — Validation, Editing, and Estimation 
15 WAN— Wide Area Network 

WFM — Work Flow Manager 

BACKGROUND OF THE INVENTION 

The reading of electrical energy has historically been 

20 accomplished with human meter readers that came on-site to 
the customers' premises and manually documented the 
readings. Over time, manual meter reading has been 
enhanced with walk-by or drive-by reading systems that 
utilize radio communications between the meters and a 

15 meter reading device. The information that these walk-by 
and drive-by systems collected increased, but still the func- 
tions provided by the communication systems were limited. 

More recently, over the last few years, there has been a 
concerted effort to automate meter reading by installing 

30 fixed networks that allow data to flow from the meter to a 
host computer system without human intervention, such 
systems have been referred to in the art as Automated Meter 
Reading (AMR) systems. AMR systems have gained interest 
because there are approximately 150 million installed 

35 meters, of which 17 million are considered to be "hard-to- 
read" because of location, etc. A limitation in these conven- 
tional AMR systems is that they typically use only one type 
of communication infrastructure to gather data. For 
example, the AMR system may receive data from meters via 

40 one of a fixed proprietary RF communications 
infrastructure, the public switched telephone network or 
power line transmission. This one-infrastructure communi- 
cation of data has led to the development of incompatible 
AMR systems that are tied to that particular communications 

45 infrastructure, utilize proprietary devices and protocols, and 
have unacceptably low data rates. Such implementations are 
also lacking because RF coverage is limited, and public 
switched telephone network and power line transmission 
solutions require relatively long periods of time to commu- 

50 nicate data from the meter. 

In addition to the limitations regarding communication 
infrastructures, conventional AMR systems are not easily 
adaptable to changing requirements of both the energy 
provider and the energy consumer. For example, while most 

55 meters measure energy monthly in kWh or Time-of-Use 
(TOUT), rising consumer demand for daily reads of kWh or 
TOU, load profile metering along with demand, outage, 
power quality and tamper monitoring capabilities will render 
conventional systems obsolete. For example, conventional 

60 AMR systems collect data via a pulsed input, and over a 
period of time to determine energy usage or may create a 
load profile. These systems, however, are not capable of 
reading data from newly developing intelligent meters that 
provide load profile information and the like to the AMR 

65 system. 

A further limitation of the conventional AMR system is 
that they do not accommodate the requirements of end-user 
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systems (e.g., billing systems, energy management systems responds to another vendor's interrogation pulse and tricks 

and supervisory control systems). Theses systems are typi- the other vendor's reader into thinking that it is communi- 

cally standalone systems, separate from the metering sys- eating with one of its own meters. The interrogator and the 

tern. One of the primary reasons that the requirements of data gathering system may communicate in a synchronous 

end-user systems are not met is because of the above- 5 or asynchronous manner depending on the vendor's imple- 

mentioned limitations that conventional AMR systems were mentation 

designed as proprietary systems rather than open systems. j Nq c{ cn (iR ^. Q 

These systems generally outpu he meter data in a raw Communication Network for Remote DaU Generating 

format that is not compatible with the end-user systems and Stations „ disdoscs a ^ arca communications networ £ 

that must be converted for use. Thus, conventional AMR 10 ^ da(a M & m q{ elcctric meters 

systems do not perform validation, editing and estimation of for transmission * a central data tenninaL Information is 

the outpu data and require a relatively high amoun of transmiUed from network modules to remole cdl 

manual intervention to transfer data from the AMR system whicfa ^ ^ mformation t0 a central dala 

to end users for farther processing. yU intermediate data lenninaIs ^ network ser- 

Yet another limitation of conventional AMR systems is 15 vice modules transrait data packels over R p transmission 

that metering data has been captured and managed using Unks [Q the remote ceI1 nodes Iocated at approximately 0 .5 

traditional mainframe or two-tiered client/server archilec- mflc intervalSj for examp ie, on utility poles or a building, 

lures. While mainframe and client/server solutions have ^ rcmole ^ nodcs pcriodically forward information via 

been up to the present relatively successful in addressing the RF transmission links t0 the intermediate data terminals. The 

needs of utilities and their customers, AMR Systems are 20 mtermcdiate data terminals are located at 4 mile intervals, 

becoming far too large and complex for conventional tech- Tfae intermedia(e data terminals communicate to the central 

nologies because of the amount of data flowing m and out of data terminal via various different types of links including 

the system (e.g., it may be necessary to store and process telephone Iines> T1 carriers> fiber optic channels, coaxial 

data from daily or hourly meter reads from millions of caWcs> microwavef or satc lhte. 

meters). As data requirements steadily increase in an auto- 75 fI ~ n > v , c r ™ <™ . o.- • u . 1 <*i ^ 

, y , 4 , .... , . f A " U.S. Pat. No. 5,590,179, to Shincovich et al., entitled 

mated meter reading system, traditional mainframe and (( _ . ' ' . t „ ,. ' 

, , t a' * "u t a * ™^ Remote Automatic Meter Reading Apparatus discloses an 

two-tiered architectures (non-distnbuted systems) expen- , ■ . . . j- c .* 1 

...... . pnn a * adaptor to provide automatic meter reading 01 conventional 

ence limitations in memory, CPU capabilities, and storage , y A . , t . . ° a t . t 

, - , f 1 , . a- ,u watthour meters without requinng modifications to the 

capacity because a crowing amount of data tratric over the , . ■ . . . j tm_ 

; , 1 j . if «.i 1 .t, . u •« ..r a meters or the socket to which the meters are mounted. The 

network leads to bottlenecks that result in performance 30 . . . . , A , . . 

.... , t . ,. , , . t . , . f « iL adaptor is raterconnected between the meter and the socket 

limitations as data is shipped between the database and the , *\ , , . . , . . . 

i- . j j • *u JT . u u m ~ 1 and includes internal telephone communications circuitry, 

client, and records m the database can become locked when _ . , _ , 4 \ . . . t „ . ' 

.. / • , 1 1 j * * ** 11 ,. Dunne a predefined transmission window, a controller in the 

client programs need to lock data to use it. Upgrading these , . ^ . u .u * .1. -3 • u 

. . ■ tu 1 a « -| - t JT* adaptor changes modes such that the adaptor may be con- 
systems to increase the load capability and performance v , . * . , , , * . 
J . . . . . . . r T j JV . f tacted via telephone to send data to a central utility site. 

requires bringing the system down. In addition, the cost 01 35 r 

maintenance and upgrade of these systems increases as Also known are distributed networks for communicating 
companies attempt to solve client/server performance prob- data from devices havin S dissimilar formats and/or prob- 
lems and scalability issues by purchasing bigger and faster cols. U.S. Pat. No. 5,619,685, to Schiavone, entitled "Run- 
machines Tim e Dynamically Adaptive Computer Process for Facili- 

In addition to limitations noted-above in conventional 40 tatin § Communication between Computer Programs" 
AMR systems, perhaps the greatest limitation of the existing dlsdoses a s y stem whereb y two dissimilar software pro - 
AMR systems is that the electric utility marketplace is g rams ma V communicate with each other on a distributed 
moving towards deregulation. Under deregulation, utility network b * ma PP in £ in P ut and 0Ut P ut biocks of memory ' 
customers will be able to choose their electric service In addition to the above system, there are specific 
providers. As a result, the deregulated marketplace has 45 examples of AMR products in use. A first is MV-90, which 
created many new business entities, which will place addi- is a product sold by Itron/UTS. While MV-90 supports 
tional demands on AMR systems. For example, in multiple electric meter manufacturer protocols, as well as 
California, a Meter Data Management Agent (MDMA) has several gas meters, gathers load profile, time-of-use, con- 
been created which is respoasible for collecting and pub- sumption and demand data, and performs some form of 
lishing the data required for billing. Further, the MDMA 50 meter data validation and issues alerts/alarms, the MV-90 
requires that settlement quality data be provided as the interfaces only to a corresponding proprietary billing system 
MDMA publishes data to multiple business entities, includ- (i.e., the MV-PBS Power Billing System). A further limita- 
ing the ESP, the UDC and potentially other ancillary services lion is that MV-90 is a DOS-based AMR system, and 
(e.g., third party billing companies, etc.). However, conven- therefore is small scale solution and is not scalable to 
tional AMR systems were not designed to accommodate the 55 accommodate large scale entities. In addition, MV-90 is 
demands of a deregulated market place nor do they provide limited to communicating with meters via a single telephone 
such capabilities. Further, conventional AMR systems do modem interface, therefore is considered only a tactical 
not accommodate the needs of commercial and industrial solution for many energy service providers. Still further, 
(C&I) and residential customers who are interested in deter- MV-90 has not been designed to accommodate and support 
raining usage statistics. 60 multiple deregulated business entities and specific regula- 

Specific examples of conventional AMR and AMR-type lory agency validation and estimation schemes, 
systems are described in the prior art. U.S. Pat. No. 5,602, An example of anothei AMR product is MAPS, which is 
744, to Meek et al., entitled "Universal Send/Receive Utility offered by Schlumberger. MAPS is a client-server, UNIX- 
Usage Data Gathering System", which discloses a universal based AMR system that collects data from water, gas and 
utility usage data gathering system that can respond and 65 electric meters. The MAT'S host software provides 
transmit recorded utility consumption to readers manufac- scheduling, network management, access to usage and load 
tured by other vendors. A "buried" emulated protocol profile information, and analysis of power usage. Usage 
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information may be shared with other systems such as information, the canon comprising canonical elements that 

billing. While MAPS may be more robust than MV-90, it too are used to interpret data contained within the input file, 

is limited by the number of meter end points from which Each canonical element is an abstraction, and each division 

information may be collected. Further, there are no data 0 r part of each the element is subsequently defined in terms 

validation or estimation schemes, and MAPS will not 5 0 f i es s abstract elements until resolving to a concrete ele- 

accommodate multiple market entities. mcnt can0 nical elements are assigned attributes that 

In view of the limitations of conventional AMR and define qualities of the canonical elements. Relationships 

AMR-type systems, the AMR system of the present inven- cxist whcn the domain contains data that is dependent upon 

tion addresses the needs and limitations of known systems otner data in the domain. The input map and the output map 

by providing an end-to-end system that combines 10 are create d in accordance with the canon, and describe the 

communications, data warehousing, processing and consoli- intended output in terms of the canonical elements. In 

dation as well as presentation and standard application addition, the input map defines a function of each compo- 

interface options. In particular, the present invention pro- nent 0 f me mput Q\ e ^ terms 0 f me canon being used, and 

vides an all-inclusive, highly automated solution by provid- me ou tput map defines a function of each component of the 

ing an integrated system that is capable of receiving data 15 outpu t file in terms of the canon being used. The input and 

from a plurality of dissimilar metering devices and commu- output maps further comprise attributes about canonical 

nications networks, managing the data, and communicating elements, modifiers for canonical elements having specific 

the data to a plurality of applications and end user systems. values, conditional statements that further define a function 

The AMR system of the present invention is adapted to of the canonical elements having specific values, tokens that 

communicate with legacy systems and other proprietary 20 spec jfy a format of the values in a particular map, and 

systems. actions that specify the format of certain parts of a file. 

In order to provide such communication with legacy According to a further feature of the present invention, the 

systems and proprietary systems, conventional AMR sys- canonical mapper further comprises an interactive translator 

terns typically require that the external systems import data utility t0 tcst thc actual translation of the input file to be 

to, or export data from, the AMR system using the format of 2 5 mapped for the translation process, the test being performed 

the AMR system or in a limited flat file format. Such in acC ordance with the canon, the input map, the output map, 

limitations lead to incompatibilities among systems and anc j tne j n p Ut 

prevent systems from communicating with each other. Such According lo another fea ture, the translator utility per- 

incompatibilitics will present extreme difficulties in the forms the conversion across domains in accordance with the 

deregulated environment. The present invention overcomes 3 o input map> ^ c output ma{)) and the input file to create the 

such limitations as noted below. Qutpul fik The trans , ator utility may also mn in a headless 

SUMMARY OF THE INVENTION mode. 

In view of the above, the present invention, through one According to another aspect of the present invention, 

or more of its various aspects and/or embodiments provides 35 there is provided a method of mapping an input file to an 

one or more features and advantages over the prior art, such output file comprising across domains comprising creating a 

as those noted below. canon, the canon comprising canonical elements; creating 

The present invention is directed to a computer system i°P ut and 0Ut P ut ma P s in accordance with the canon to 

having a canonical mapper to translate an input file from an perfonn the conversion of the input file; testing the conver- 

input domain to an output domain. The canonical mapper 40 slon i and mapping the information from the input map to the 

comprises a canons utility which builds a canon, the canon 0Ut P m ma P 10 create the 0Ul P ut me - 

being a tree relating all data attributes within a domain of According to a feature of the method, creating a canon 

information, and the domain being a collection of data that comprises defining a root from which other subordinate 

has a same data format, a maps utility which creates input parts of the canon stem, the root and subordinate parts 

and output maps that specify the translation from the input 45 comprising the canonical elements; defining children of the 

domain to the output domain, and a translator utility to root, the children defining specific information about the 

perform the translation of the input file to an output file. The root; and defining relationships of the canonical elements, 

input map is a data structure that describes a format of the According to another feature of the method, creating input 

input domain and the output map is a data structure that and output maps comprises selecting each component of the 

describes a formal of the output domain. 50 input file and defining its function in terms of the canon; 

According to a feature of the present invention, the defining attributes about the canonical elements; defining 

canonical mapper converts files over at least two mapped tokens, the tokens specifying a format of the results of 

subdomains, the at least two mapped subdomains being the mapping the input file using the input and output maps; and 

same root domain. defining actions to structure the appearance of portions of 

According to another feature of the present invention, the 55 lhe in P ul file or tne 0Ut P ut file - 

input map and the output map are derivation trees, and the According to yet another feature, defining attributes about 

canonical mapper utilizes the input map and the output map the canonical elements comprise defining modifiers for the 

to build a scanner/parser for the input file domain. The canonical elements, the modifiers determining if a value of 

canonical mapper traverses the input map lo parse data from a particular canonical element is required, if the value 

the input file into a canonical list. The canonical mapper then 60 appears more than once, if the canonical element includes a 

maps from the canonical list to the output domain to series of the values, or if the canonical element is required; 

generate the output file by traversing the output map and and defining identifiers, the identifiers being constant values 

re- interpreting a corresponding element in the canonical list within the input file. 

such that the corresponding element conforms to thc output According to another aspect of the present invention, a 

domain. 65 canonical mapper is provided in a server residing within a 

According to yet another feature, the canon comprises an multi-layered distributed software architecture that receives 

abstract template that describes a structure of the domain of and processes data, the server comprising a data repository 
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to store the data, at least one external interface to commu- 
nicate with systems external of the server, a services sub- 
system comprising distributed services, the distributed ser- 
vices running on application servers within the distributed 
architecture, middleware software to facilitate scalability, s 
transaction processing, and mapping of objects to the data 
repository, and application frameworks to facilitate access to 
the data repository and the creation of processes compliant 
with the middleware software. The canonical mapper com- 
prises a canons utility which builds a canon, the canon being 10 
a tree relating all data attributes within a domain of 
information, and the domain being a collection of data that 
has a same data format, a maps utility which creates input 
and output maps that specify the translation from the input 
domain to the output domain, and a translator utility to 15 
perform the translation of the input file to an output file. The 
input map is a data structure that describes a format of the 
input domain, and the output map is a data structure that 
describes a format of the output domain. 

According to a feature of the present invention, the 20 
canonical mapper server resides in a mapping subsystem 
which provides for customization of file formats for export- 
ing data from and importing data to the server. 

According to yet another feature of the invention, the 
server further includes a mapping interface server that 25 
interfaces with the canonical mapper, wherein the mapping 
interface server provides middleware service requests from 
the services subsystems. The mapping interface server inter- 
faces with the canonical mapper server using a socket 
connection, and provides a service that allows a service in 30 
the services subsystem to specify the input file, the input 
map, the output file, and the output map. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The foregoing summary, as well as the following detailed 35 
description of the preferred embodiments, is better under- 
stood when read in conjunction with the appended drawings. 
For the purpose of illustrating the invention, there is shown 
in the drawings an embodiment that is presently preferred, 
in which like references numerals represent similar parts 40 
throughout the several views of the drawings, it being 
understood, however, that the invention is not limited to the 
specific methods and instrumentalities disclosed. In the 
drawings: 

FIG. 1 illustrates an overview of an AMR system archi- 
tecture in accordance with the present invention; 

FIG. 2 illustrates an exemplary hardware configuration of 
an AMR Server for a small-scale deployment; 

FIG. 3 illustrates the software architecture of the AMR 
Server including the three-tiered system, middleware 
products, a database repository and external interfaces; 

FIG. 4 expands the AMR Application and Infrastructure 
Subsystem block shown in FIG. 3; 

FIG. 5 illustrates the relationship of a delivery schedule to 
a Schedule Subsystem; 

FIG. 6 illustrates the relationship of a Mapping Interface 
Server to the AMR Subsystems; 

FIG. 7 illustrates the process of converting a file between 
two applications; 6Q 

FIG. 8 illustrates a Log/Trace Subsystem; 

FIG. 9 illustrates in block diagram format a client GUI 
connected to the AMR Server; 

FIG. 10 illustrates a Supplier Subsystem in accordance 
with the present invention; 65 

FIG. 11 illustrates the process of a synchronous requests 
to the AMR Server; 
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FIGS. 12 A and 12B illustrate the process of an asynchro- 
nous requests to the AMR Server and asynchronous notifi- 
cations from the AMR Server; 

FIGS. 13 and 14 show the interaction between manager 
servers, proxies, and implementation servers within a DAO 
Subsystem; 

FIG. 15 illustrates the process performed each time a 
method is invoked on a proxy; 

FIG. 16 illustrates an exemplary structure of the database 
designed as a high-level object model; 

FIG. 17 illustrates the logical architecture of the account 
management subsystem; 

FIGS. 18A-D illustrate the logical architecture of the 
capability manager; 

FIG. 19 illustrates the logical architecture of the meter 
manager; 

FIG. 20 illustrates the logical architecture of the rate 
manager; 

FIG. 21 illustrates the logical architecture of the reading 
management server; 

FIGS. 22A-B illustrate the logical architecture of the 
schedule manager; 

FIGS. 23A-E illustrate the Schedule Manager; 

FIG. 24 illustrates the logical architecture of the System 
Parameters; 

FIG. 25 illustrates the logical architecture of the Trans- 
lation Service; 

FIG. 26 illustrates the process of an on-request meter 
reading; 

FIG. 27 illustrates a canonical element "BOM"; 

FIG. 28 illustrates the Canon "Costing"; 

FIG. 29 illustrates a main screen of the activity plan 
builder in accordance with the present invention; 

FIG. 30 is a graphical representation of the various paths 
available for a. particular workflow; 

FIG. 31 illustrates a modifying a particular Task to 
execute, undo, or finalize an operation; 

FIG. 32 illustrates modification of an operation; 

FIG. 33 illustrates slot names within a blackboard object 
that contain the specific value types used to execute the 
operations; and 

FIGS, 34A-D illustrate the interaction of threads within 
the Validation, Editing and Estimation subsystem. 

BRIEF DESCRIPTION OF THE APPENDICES 

In order to further facilitate the detailed description of the 
present invention, reference is made to the noted plurality of 
appendices by way of non-limiting examples of preferred 
embodiments of the present invention, which are provided 
with respect to the various features, operations and functions 
of the invention, and wherein: 

Appendix A contains top level interaction diagrams illus- 
trating the various servers and objects invoked for an 
operation; and 
Appendix B contains the database structure for the AMR 
Server of the present invention. 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

The AMR Server of the present invention advantageously 
offers a large-scale system solution to address the manage- 
ment of metering data and the administration of the systems 
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that perform the management. The AMR Server is designed cient. A further advantage of distributed systems is that the 

to provide business entities in the power industry with an hardware components of a distributed system can be located 

automated meter reading system that could serve as a single and added where they are needed. Therefore, as needs 

source for metering data. change over time, the components of a distributed system 

As will be described in detail below, the AMR system of s can De easily moved and reconfigured without impacting 

the present invention is designed as a distributed system to performance. Distributed processing allows the AMR Server 

accommodate the variety of legacy systems and platforms 15 to be scalable and to grow, as the data management needs 

existing in the current market, and is scalable, flexible and change. Further, by distributing large amounts of data across 

adaptable. The system is adapted to accommodate customer- multiple servers, higher throughputs are achieved resulting 

to-customer differences in requirements, business logic, and 1Q in better performance and management of data. Distributed 

regulatory requirements. systems can provide greater availability as planned outages 

An overview of the AMR system 10 architecture is occur and are immune to single points of failure. Individual 

illustrated in FIG. 1. The AMR System includes an AMR computers or links can be disconnected from the system for. 

Server 15 that collects, loads, and manages system-wide testing, repair, or modification without a negative impact on 

metering data from electronic or electromechanical meters the system. In addition, the AMR Server 15 will provide 

60 located at customers' premisses 70 and. routes it auto- SNMP support supplemented with other tools, 

matically to upstream business systems 50 (collectively, the Communication with the meter or meter modems is 

External Application and Communication Systems). Energy preferably supported as server initiated and meter modem 

providers can capture consumption and interval meter data initiated calls. Two-way communications allows both ser- 

for hundreds of thousands of meters 60, deliver it directly to yice id and end . users to have functionalities which 

business functions and system 50, and ultimately supply the 20 ^ ^ ^ ^ Some Qf ^ 

£V° T F^T *?< ™ n ,lrv'flr would include: outage alerts, tamper notification, in-home 

addition, the AMR Server 15 serves as a repository lor , * i . • • ? * 

existing business application systems 50 belonging to display of electric mformaUon, meter programming, remote 

Energy Service Providers (ESPs) and/or Utility Distribution monitoring of power quality, customer service diagnostics 

Companies (UDCs), such as billing, Customer Information 25 and more " The communications infrastructures supported in 

Systems (CIS), Customer Service, and Outage Management the AMR System 10 include, but are not limited to, CDMA 

Systems (OMS). (Code Division, Multiple Access), Telephone and Interna- 

Metering data may be collected via communications tional DAA, ARDIS, X.25, RAM, ReFlex, AMPS (Analog 

servers 30 from a variety of dissimilar meters 60 and Mobile Phone System), CDPD (Cellular Digital Packet 

transmitted using multiple dissimilar types of communica- 30 Data), TDMA (Time Division Multiple Access), and AMPS 

tion media and infrastructures 80. The AMR Server 15 is (Digital Analog Mobile Phone System), 

designed to compensate for the complications introduced by FIG. 2 illustrates an exemplary hardware configuration of 

variations in dissimilar meters 60 and communication media the AMR Server 15 for a small-scale deployment. The 

80, and to present an abstracted view of the entire metering exemplary hardware configuration assumes an initial 

system to end-user business applications 50. The AMR 35 deployment configuration with a design scope of about 

Server 15 allows various business systems 50 to interact 10,000-meter points. As illustrated, the exemplary initial 

with meters 60 and metering data without the constraints of configuration includes Sun E3000 Database Server (or other 

system configuration details. For example, the AMR Server enterprise level server) running Oracle® RDBMS, and the 

15 allows a billing system to create a billing schedule for a Encina® Monitor Suite; a Sun Ultra 2 running all other 

collection of meters 60 and have this data delivered to a 40 distributed systems; an EMC Disk Array, a Veritas ATLDLT 

specified location according to the schedule. The collection Backup System; and a Compaq Proliant 5000 running a 

of meters 60 to be billed may be of different meter types and Canonical Mapper (discussed below). This configuration is 

distributed across various communication media 80 each scalable to accommodate greater numbers of meters, as 

having different network constraints that complicate the data noted above. The Communication Servers 30 of this base 

collection. Meanwhile, the billing system is not required to 45 configuration run over a Wide Area Network (WAN) and can 

have knowledge of these complexities. be scaled toward a geographically dispersed telephone solu- 

As will be described in greater detail herein, the AMR tion or a wireless communication system (e.g., Ardis, CDPD 
Server 15 architecture is represented as a .cooperating set of or PCS). The communication server 30 may comprise an 
services running in a distributed architecture. The distrib- RCS 250, available from ABB Power T&D Information 
uted architecture of the AMR Server 15 is designed with 50 Systems, Raleigh, N.C., as configured in FIG. 2. 
three tiers, rather than the traditional two. A three-tiered Turning to the software implementation of the AMR 
system advantageously allows clients make small requests Server 15, it is noted that in recent years object orientation 
for services, instead of large requests for data, via applica- in software development has demonstrated that encapsulat- 
ion servers that can be programmed in ways that they do not ing logic or behavior with data is useful in building flexible 
create lock contention in the database. Application servers 55 systems. However, new systems require dynamic business 
can be executed on multiple machines simultaneously in a functionality based on changing customer needs or customer 
configuration called "application replication" which spreads differences. Three-tier architectures are implemented by 
client loads across multiple machines and enables higher using views and simple APIs to interface with a domain 
availability, scalability, and performance. Additionally, the server that in turn deals with encapsulated business objects 
total number of connections into the database can be reduced 60 that are persistently stored in the database. This works well 
because application servers manage client "sessions" and to abstract business logic from applicator logic; however 
multiple clients can share database connections. The archi- they are limited in that when business lo£u; is changed, the 
tecture is designed to be scalable from a small utility business logic objects must be re-coded within the system, 
(approximately 10,000 meters) to a large utility (3 million The present invention improves upon traditional three- 
meters or more). 65 tiered systems to be flexible and to accommodate dynamic 

The AMR Server 15 is preferably a distributed architec- business requirements. This flexibility is provided by the 

ture because such systems are flexible, scalable, and effi- AMR Server 15 as an extension made to the traditional 
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three-tiered approach. This extension is to extract business 
logic into objects called Activity Plans. Activity Plans or 
work flows control the flow of work in a system. The 
Activity Plans are an independently driven set of flexible 
and cooperating services that do not require programming, 
as the business logic is not hard -coded into the system, but 
appears as tasks in Activity Plans. The Activity Plans can 
thus accommodate different business models. Further, the 
Activity Plans contain a well-defined interface, and encom- 
pass dynamic rules. 



distributed environment presents major challenges as users 
are dispersed at various locations and need to be authorized 
to access the system. An appropriate level of access is 
determined for each of the users that are authorized to access 
the system. Also, the security privileges are verified against 
the actions the users wish to perform. 

The Distributed File Service (DFS) provides the ability 
for programs to access files located on a file server as if the 
files were located on the local system's hard disk. The 



Referring now to FIG. 3, as part of the three-tiered 10 distributed application does not have to know where the files 



system, middleware products are used to promote scalability 
and adaptability in the AMR infrastructure and architecture. 
For example, middleware products such as the Common 
Object Request Broker Architecture (CORBA) and Distrib- 
uted Computing Environment (DCE) 112 may be used. 
However, it is preferable to use DCE as CORBA does not 
provide some key capabilities (e.g., Distributed Services, 
Distributed File Services, Distributed Security, and Trans- 
action Processing support) that are preferably provided in 
the AMR Server 15. Further, CORBA is a relatively new 
technology and lacks support for all the major platforms 
(e.g., PCS to mainframes). 

The DCE environment 112 consists of a suite of inte- 
grated software services that are part of a computing sys- 
tem^ infrastructure. DCE 112 plays an important role in 
critical areas of computing, such as security, Internet/ 
Intranet computing, and distributed objects. The DCE tech- 
nology 112 was designed to operate independently of the 
operating system 118 and networking technology that appli- 
cations use. As a result, it enables interaction between clients 
and servers in any environment. As shown in FIG. 3, the 
DCE technology comprises software services that reside 
logically "on top" of the operating system 118. These 
services employ lower-level operating system 118 and net- 
work resources to accomplish their tasks. 

The DCE services 112 include a Remote Procedure Call 
(RPC) that facilitates client-server communication so that 
applications can effectively access resources distributed 
across a network, a Security Service that authenticates the 
identities of users and authorizes access to resources using 
a method for user and account management, a Directory 
Service that provides a single naming model throughout the 
distributed environment, a Time Service that synchronizes 



20 



25 



are located or that the files are not located locally on the disk. 
DFS has a single, consistent, and global namespace for all 
files, which means that every node in the network identifies 
the same file by the same name and sees it located in the 
35 same directory. 

The DCE Cell Directory Service (CDS) provides a reli- 
able mechanism by which distributed applications can asso- 
ciate information with names. The primary purpose of CDS 
is to allow clients to locate servers. The Cell Directory 
Service implements a hierarchy of names arranged in a tree 
structure in which every item has exactly one parent and 
zero or more children. The CDS provides naming within a 
local set of nodes called a cell. 

Within the distributed environment, transactions are 
monitored to ensure proper functioning of the system. In the 
AMR Server 15, Encina® 106 (ver 2.5 or higher), is used to 
monitor transactions (see FIG. 3). Encina® 106 is a family 
of products, offered by Transarc® Corporation, for 
developing, executing, and administering distributed trans- 
action processing systems. A distributed system consists of 
multiple software components that run in separate indepen- 
dent processes on different machines in a network. Trans- 
actions are a tool for distributed systems programming that 
simplify failure scenarios. A transaction is a set of operations 
that transforms data from one consistent state to another. 
This set of operations is an indivisible unit of work, and in 
some contexts, a transaction is referred to as a logical unit 
of work. The operations that make up a transaction typically 
consist of requests for existing data, requests to modify 
existing data, requests to add new data, or any combination 
of these requests. 

Transactions provide several important properties 
referred to as ACID (Atomicity, Consistency, Isolation, and 



the system clocks throughout the network, a Thread Service 45 Durability) properties. Atomicity refers to the property that 

that provides multiple threads of execution, and a Distrib- a transaction is either successful or unsuccessful. A success- 

uted File Service that provides access to files across a ful transaction is said to commit. An unsuccessful transac- 

network. Each will now be briefly described. tion is said to abort. Any operations performed by an aborted 

The DCE RPC facility eases distributed application devel- transaction are undone (rolled back) so that its effects are not 
opment by modeling distributed processes as a subroutine 50 visible. Consistency refers to the property where each trans- 
and the caller of that subroutine. The subroutine is the action transforms distributed data from one consistent state 
implementation of the server and the caller of the subroutine to another. The application program is responsible for ensur- 
is the client. The DCE RPC provides the developer with ing consistency. Isolation refers to the property where each 
basic services that the application developer would other- transaction appears to execute independenlly of other trans- 
wise have to implement, such as communication facilities 55 actions that are running concurrently. The effects of the 
required to communicate between the client and the server, transaction are not visible to other transactions until the 
mechanisms for the client to locate the server within the transaction completes (either commits or aborts). The trans- 
network and data transportation across the network, and data actions appear to be serialized, with two or more transac- 
conversion from one format to another as needed. tions acting as though one completed before the other began, 

The Distributed Time Service (DTS) serves two major 60 even though they executed concurrently. Durability, also 



purposes. The DTS service keeps all computers within the 
network reasonably close to the same time (even if their 
hardware clocks do not run at exactly at the same rate) and 
maintains the network nodes connected to a public time 
service in synch. 

The Distributed Security Service (DSS) ensures that ser- 
vices are provided only to designated parties. Security in a 



65 



known as permanence, refers to the property where the 
effects of a transaction are permanent once completed. 
Preferably, transactions are used to control and moderate 
access to a database. 

The transactions are monitored by the Encina® Monitor 
(not shown). The Encina® Monitor provides the infrastruc- 
ture for building and deploying client/server applications, 
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such as an environment that shields application program- 
mers from the complexities of distributed computing, fault 
tolerance across heterogeneous environments to provide 
high performance and transactional integrity, and a compre- 
hensive management environment that enables widely dis- s 
tributed Monitor-based systems to be administered as a 
single, logically defined system. The Encina® Monitor 
provides methods for simplifying load balancing and sched- 
uling. These methods include assigning a priority to each 
application server, multiple processing agents for each appli- 10 
cation server, and multi-threaded application servers. 

Transactions are preferably isolated from one another to 
prevent other transactions from accessing data that a par- 
ticular transaction is using until the transaction is complete. 
This could result in locking the database and preventing 15 
other users from accessing the data until the transaction 
commits or aborts. An important design goal of transactional 
applications is to complete transactions quickly, unlocking 
locked data and giving other transactions access to data as 
quickly as possible. This feature is accomplished via a 20 
Recoverable Queuing System (RQS), which will be 
described below. 

The Encina® Structured File Server (SFS) is a record- 
oriented file system that provides transactional integrity, 
log-based recovery, and broad scalability. SFS uses struc- 25 
tured files that are composed of records. The records them- 
selves are made up of fields. The structured file system is the 
collection of data managed by a single structured file server 
(SFS). All access to a structured file system is through a 
single server, using a special type of open file descriptor 30 
(OFD). 

As noted above, the AMR Server 15 is an object-oriented 
system that retrieves and stores a large amount of persistent 
data. While an object-oriented database or a relational 35 
database could be implemented in the AMR Server 15 to 
store the persistent data, object oriented (OO) databases are 
new and are not really proven in large distributed systems 
because they are unable to handle the large volume of data. 
Relational databases have been established, proven, and 4Q 
implemented for years and since relational database tech- 
nology entails transactional integrity, locking and concur- 
rency solutions, and distributed databases. 

However, it is preferable to use a combination relational 
database/object-oriented solution in the AMR Server 15. 45 
The AMR Server 15 uses a relational database with an 
object-oriented design on top of the relational strategy. The 
database preferably comprises Oracle® RDBMS 116, and 
the Encina® 106 application servers (Meter Manager, Rate 
Manager, etc. to be discussed below) use the 00 design to 50 
implement its mapping to the relational data in Oracle. The 
Oracle® RDBMS 116 shown in FIG. 3 is available from 
Oracle® Corporation, Redwood Shores, Calif. 

In order to address the mismatch between OO develop- 
ment and a relational database, Persistence software (ver 55 
3.4.2 or higher) 108 was selected, as shown in FIG. 3, 
Persistence software 108 is available from Persistence Soft- 
ware Inc., San Mateo, Calif. Persistence 108 performs 
object -to -relational mapping which is the tedious translation 
and mapping from the two-dimensional relational database 60 
120 to the much more complex object structures in the AMR 
Server 15. Persistence 108 alsoj performs object caching 
which provides the AMR Server 15 with a "local copy 1 ' of 
the database to improve performance and monitors and 
updates database changes in the cache. In addition, Persis- 65 
tence 108 provides for database independence which ensures 
that the database functionality works consistently in the 



AMR Server 15 regardless of the type of relational database 
system behind Persistence. This later capability, although 
not essential, is preferable. 

The Persistence software 108 provides a platform- 
independent, database-independent class library interface to 
a variety of Relational Database Management Systems 
(RDBMS). The Persistence software 108 consists of the 
Persistence Object Builder and the Persistence Object Server 
class libraries. The Persistence Object Builder automatically 
generates object-oriented C++ classes for use when building 
high-performance relational database applications. The Per- 
sistence Object Builder creates the Persistence-generated 
C++ classes based on a database schema designed for the 
AMR Server 15. The Persistence Object Server class library 
supports Persistence-generated classes and mediates the 
RDBMS activity. The generated classes contain derived 
methods for all common database operations. 

The AMR Server 15 preferably accesses the relational 
database 120 transactionally. Such a capability is provided 
via Transaction Processing (see XA Protocol 110 in FIG. 3). 
The relational database management system (RDBMS) 116 
or one of the Encina® 106 resource managers (such as SFS 
or RQS) preferably supports transactional semantics which 
ensure that if a transaction is aborted, any changes to the 
database are undone. The XA specification describes what a 
resource manager does to support transactional access. 

Briefly, X/Open, an international standards body, defines 
the components that interact in a typical transaction pro- 
cessing system. These include the Transaction Manager 
(TM), which manages distributed transactions and decides 
whether they commit or abort; the Resource Managers 
(RM), which store recoverable data; the Communications 
Manager (CM), which communicates between transaction 
managers and other components; and the application code. 
There are also X/Open standards for the interactions 
between these components. The most commonly- 
implemented specification is the XA Specification, which 
defines the interaction between the TM and the RM. 

Typically, Encina 0 106 acts as the TM, and XA-compliant 
databases are the RMs. The XA specification defines the 
interaction between the RM and TM. In Encina 0 106, the XA 
protocol 110 is implemented in the TMXA module. TMXA, 
in turn, registers callback functions with TRAN to determine 
when transactions are prepared, aborted, and committed. It 
also registers callbacks with the "threadTid" module to be 
notified when a new transaction is present. The XA protocol 
110 specifies how the TM interacts with the RM. However, 
it does not specify how application code interfaces with the 
RM. Applications programmers using the XA protocol 110 
use the TM API to begin and end transactions, and use the 
RM's native API to access and modify data. 

The XA specification 110 is not a network communica- 
tions protocol, but rather it is a set of functions that are 
implemented by the RM and called by the TM. There are 
also some functions implemented by the TM that will be 
called by the RM. It is important that the TM be able to 
manage transactions on several RMs at once. So, these XA 
functions are provided to the TM by a table of function 
pointers. This structure is called the "XA switch." Defined 
by each RM, the switch includes function pointers to the 
functions in the XA API, and flags that specify the exact 
behavior of the RM. 

Referring again to FIG. 3, a Database Access Object 
Framework 102 and a Distributed Services Framework 104 
(collectively called Application Frameworks) are built on 
top of the middleware products to simplify the use of these 
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products and alleviate the need of programmers to have Tag value list is a class that encapsulates the concept of a 

detailed knowledge of creation of applications that initialize string of tag -value pairs, and provides various functionality 

and establish the required environment for these products. for manipulating and extracting information from such a 

The Database Access Object Framework 102 hides the string. The concept of a tag-value list is useful when a 

detailed implementation of the database 120, as represented 5 function can take a variable and diverse number of param- 

by the Persistence objects, from the application by providing eters that can be more easily realized in a string form of 

distributed object proxies. The Distributed Services Frame- tag-value pairs that may have special meaning within the 

work 104, provides classes that hide the details of how to function. 

create DCE/Encina® compliant servers (processes). The Each server object in the AMR Server 15 is a subclass of 
Distributed Services Framework 104 also shields the appli- JQ the Distributed Services Framework AppServer classes. The 
cation from the underlying communication mechanism AppServer classes model the concepts of RPC clients and 
(RPC or queued) being utilized. servers as objects. These classes support both synchronous 
The Distributed Services Framework 104 comprises sev- RPC based interfaces and queue -based interfaces. The 
eral utility classes, including the object store, generic object, AppServer class makes the different interface types (RPC or 
blackboard, performer and tag value list classes. The object queue-based) largely transparent to the developer. AppS- 
store is a singleton that exists within the process space of a erver provides the following generic behavior for all sub- 
module. The ObjectStore class is provided to serve as a classes. AppServer contains methods to support: Interface to 
factory for any object or atomic datatype that has been trace, logging and error reporting systems, DCE registration 
defined within the ObjectStore class mapping directory. It and ( st * rtu P (Namespace registration and Security 
. . J - . • ■ . l _i /• registration), Vendor messages required by a Concern 
can create new instances of these objects based on a string on w e r . ... c & / r 

c . , r.L i_- i_ < ? 20 Manager, Initialization of any common objects from startup 

representation of the class name of he object to be created^ fik ( ^ names ' automaUca i^ starts thrcad £ 

It also provides functionality for casting these newly created read and invoke methodg 0Q gelf from d messa 

instances to the proper datatype, so they can subsequently be opeQS mcssage and uses service name to map t0 a mcthod 

sent messages and accessed as if the object was specifically within the ob j ecl? and Decodes lag ValueLisi to provide 

instantiated the objects in the code. 25 arguments. 

Because the boundaries of communication for the AMR The AMR Server 15 may have named queues attached to 

Server 15 are difficult to define, a common mechanism for it for asynchronous requests, export interface objects that 

inter-process communication has been created. This com- represent actual RPCs that can be made to the server; where 

mon mechanism is "messaging." Pieces are easily moving each interface object can be synchronous (RPC based), 

into or out of the AMR Server 15 as needs emerge by using 30 asynchronous, or both. The server may also need to initialize 

a messaging concept for all intra and inter systems commu- and connect to resource managers, described below, 

nication. Messages are sent to named objects. A third party The AppServer classes use other utility classes from the 

or "broker" is responsible for delivering the message to the Distributed Services Framework 104. As noted above, the 

receiver and making sure the return value makes it back to Distributed Services Framework 104 contains RQS Queue 

the requester. Commonly, this type of inter-processes com- 35 Management Classes which are classes that encapsulate the 

munication is described by the CORBA standard. Typically, rqs concepts in Encina® 106 as C++ objects to reduce the 

messages are defined that are supported by all systems and complexity and redundancy typically involved with using 

use a common language called the Interface Definition RQS. The RQS allows applications to queue transactional 

Language (IDL). By building the AMR Server 15 along work to be completed at a later time. The RQS approach 

these lines, this provides for manageable changes to the 40 provides several advantages, such as preventing overloading 

AMR Server 15 in the future. of a queue -fed server when a large number of requests are 

The Generic Object class provides some of the dynamic handed to it. Also, if a server is down, the request is still 

functionality that is similar to a weakly-typed runtime bound received and placed in its queue and will be processed when 

environment such as Smalltalk. The GenericObject class is ever the server comes back up. Also, RQS advantageously 

designed to be used as an extension of the ObjectStore. An 45 provides for a transactional queuing service, such that if a 

instance of GenericObject contains a pointer to an instance request is aborted, it is placed back in the server's queue and 

of a specific type of object, and provides a "wrapper" around not lost. 

this instance. Each server may be provided with one or more 

The Blackboard class uses the framework class QueueSets. A QueueSet is a collection of one or more 

ObjectStore, GenericObject and GenericDictionary to pro- 50 queues (i.e., 1 to n number of queues) that are given a 

vide a heterogeneous dictionary which can be saved to, and priority from 1 to n. Queue class feeds messages through a 

restored from, a persistent medium such as a file or relational class to a configurable read pool to eliminate bottlenecking 

database. The blackboard may be used as a central reposi- of the queue and overrunning of the number of reads the 

tory for shared information used in an existing workflow. server would be processing. To perform such a function, The 

The blackboard may also be used to store parameters to be 55 queues are also assigned service levels in inverse order. The 

supplied to a task invoked automatically for a scheduler or priority 1 queue gets a service level of n, priority 2 queue 

alarm server. A blackboard is uniquely identified by a gets service level n-1, etc. Threads are created to service the 

number, which is represented in a datatype. queues. Also included are Queue Class which are used by 

The Performer Class (discussed above with reference to servers to enqueue items/actions according to priority/ 

RQS) has its origins in Smalltalk, where weak typing and 60 service level to servers for asynchronous processing. In 

late or runtime binding are used. However, C++ has a addition, the QueueElement Class is an abstract base class 

different and opposite ideology. Thus, Performer attempts to containing pure virtual functions getaction( ) and 

resolve this dichotomy by simulating runtime invocation of getlnterface( ). This class assumes that all QueueElements 

functions based on a RWCString representation of the contain an action and an interface name that the action will 

function name. Performer is a template class and a specific 65 be performed on. 

template instance of Performer is instantiated for each type To increase or decrease the throughput of a server, the 

of class these functions are to be executed on. number of threads is configurable on a per server basis via 
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a configuration file (e.g., 172b in FIG. 8). When a request 
comes into a server in the form of a queue element, one of 
the threads service the queue dequeues the element and 
begins the transaction. The thread then obtains the interface 
and service to be invoked from the queue element and 
messages the for that interface to invoke the function 
associated with the service name. If the service is invalid, the 
raises an exception and the thread discards the queue ele- 
ment. If the service is valid, the Performer invokes the 
appropriate function. When the function returns, the return 
status is optionally sent back to the requester of the service 
via a separate queue element where it is processed if 
necessary. 

Referring again to FIG. 3, Application and Infrastructure 
Subsystems 100 are provided, which include subsystems 
that lie on top of the middleware products discussed above. 
The AMR Application and Infrastructure Subsystems 100 
both directly and indirectly use the middleware products 
described above. RogueWave 114, is a class library of 



10 



cations would not perform inefficient queries that would 
lock out sections of the data and consume needed processing 
power. In addition, if external applications are allowed direct 
access to the database, then encapsulation is lost and any 
changes made to the structure of the database need to be 
coordinated with all external applications that have made 
direct use of the database. Instead, the AMR Server 15 
architecture provides periodic data mining from the Data 
Repository 120 into another database (see, Output Staging 
Database 122 in FIG. 3). The structure of the Output Staging 
Database 122 can remain stable and isolated from the AMR 
Server 15 applications. As changes occur in the AMR Server 
Data Repository 120, only the data mining application has to 
change. External applications can be developed using SQL 
or other commercially available report generation tools to 
obtain access to the contents of the Output Staging Database 
122. 

Referring now to FIG. 4, the AMR Server 15 uses 
independent Subsystems (SS) to accomplish large grained 



pre-compiled software used to assist in the development of 2Q business goals. FIG. 4 expands the AMR Application and 



common and routine tasks within a system. RogueWave 114 
provides many useful services that shield the AMR Server 
software from the underlying operating system 118. Rogue- 
Wave 114 is platform independent between different UNIX 
variants as well as Windows NT®. 

FIG. 3 also illustrates several external interface mecha- 
nisms that allow the AMR Application Services to interact 
with the External Application Systems 50. As illustrated, a 
DCE API 132 is provided that is based upon the DCE RPC 



Infrastructure Subsystem block 100 shown in FIG. 3 as well 
as other systems. These Subsystems house specialized ser- 
vices which may be distributed throughout the AMR Server 
15. The Subsystems are named to help locate the services 
25 within the distributed system, but Subsystems do not have 
physical boundaries. The subsystems are simply named 
places (i.e., name spaces) to conveniently group services that 
collaborate to perform a business goal. Messages are not 
sent to the Subsystems, but rather to the services (methods, 
mechanism discussed above. The individual RPC APIs 30 functions, etc.) within the Subsystems. Typically, the ser- 
provided by the AMR Server 15 will described below. vices provided by a Subsystem are contained in executables 
Another interface available to external systems is the File (servers) or provided as class libraries that perform a specific 
Based Interface 128. The file based interface 128 is provided set of services. There may be a single server within a 
because RPCs are not designed to efficiently handle bulk Subsystem (named the same as the Subsystem), or there may 
exchanges of data, like sending metering data to a billing 35 be multiple servers in a Subsystem that interact to imple- 
system. Most billing systems currently use a file-based ment the service(s). 

protocol for receiving billing data, and have specified for- AMR (Software Architecture) Subsystems are divided 
mats for the billing data file. Currently, there is no standard into two broad categories, shown as the Infrastructure and 
data format specified for use by billing systems. In view of Application Subsystems 100. The Infrastructure Subsystems 
the incompatibilities in file formats, the AMR Server 15 uses 40 provide the services and framework required to support the 
a Canonical Mapper 140a that can convert from any file Application Subsystems. The Infrastructure Subsystems are 
format to any other file format. The Canonical Mapper 140a developed as generic and reusable components. These Sub- 
builds a map which specifies the required translation to systems have no knowledge of AMRs' application domain, 
perform the conversion. The Canonical Mapper 140a advan- The Application Subsystems, on the other hand, have 
tageously allows the AMR Server 15 to quickly adapt to 45 detailed and specific knowledge about the AMR domain, 
different formats for the data without writing code and These Subsystems implement the AMR application require - 
recompiling the software. ments. For example, the AMR domain is concerned with 

The final interface illustrated in FIG. 3 is the Database meters 60, rates, accounts, metered data, etc., and the 
APIs 124. The AMR Server 15 provides the capability to Application Subsystems know how to operate on these 
populate the Output Staging Database 122 with data from 50 entities, and know their relationships. The Application Sub- 
the AMR Data Repository 120. The Output Staging Data- systems can be further subdivided into Support Services, 
base 122 schema is made public to enable external system and Data Management Services. 

application developers to produce their own database access As shown in FIG. 4, the AMR software architecture is 

routines. The AMR Server 15 does not directly provide the composed of the following Subsystems. The Infrastructure 
Database APIs 124 depicted in FIG. 3, but the architecture 55 Subsystems include Activity Management 146, Scheduler 



of the system enables these APIs to be developed while 
maintaining isolation between the business systems and the 
AMR Server 15. Future interfaces 126, such as CORBA, 
may be provided as necessary. A provision has been made in 
the AMR Server 15 for such future interfaces 126. 

Th; loading of data into the AMR Server 15 database is 
the highest volume task in the system. For this reason, the 
loading performs bulk imports of data into the database very 
efficiently. To this end, the AMR Server Data Repository 120 



138, Alarm 134, Concern Management 136, Mapping 140, 
and Log/Trace 142subsystems. The Application Subsystems 
include a GUI subsystem 92. As noted above, the Applica- 
tions Subsystems may comprise Support Services and Data 
60 Management Services. The Support Services are a group of 
subsystems that accept requests, and communicate to sys- 
tems external to AMR. Support Subsystems include a Utility 
Interface 144 and a Supplier Interface 148. The Data Man- 



agement Services store, retrieve, and format the relatively 
is not directly accessed by external applications. If external 65 large amounts of data that the system will handle. The Data 
application had direct SQL access to this database, then the Management Subsystems include a Data Access Object 
AMR Server applications could not be assured these appli- Subsystem 150 and an Export Subsystem 152. 
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Each AMR Subsystem is composed of one or more management, which holds and manages access to the black- 
software servers. As noted above, the AMR Server 15 is board for all contained tasks. The third is task state 
modeled as a set of cooperating system services and objects management, which tracks which tasks are in progress, 
encapsulated within servers implement these services. The Another responsibility is a next operation which is a directed 
capabilities of the system are viewed as the combined 5 graph rule-set for determining which task to perform next 
capabilities of its services. As used herein, cooperating based on the state of the Activity Plan. The activity plans are 
objects accomplish services. The interface to these objects is also responsible for task logging, which logs the result of 
through their public methods. Many methods may interact to tasks as they are completed. 

accomplish a service, but only a few are exposed as inter- xh e j s a discrete unit of work in an Activity Plan that 

faces to the service. All objects that cooperate to fulfill a 10 js performed by a single service in the system. An Activity 

service physically live in the process space of one or more pi an tas k ^ responsible for precondition processing which 

servers (processes running apart from the client process on predetermines the task's ability to execute based on the 

the same machine, LAN or WAN). The client or end user availability of required inputs. The task also has Activity to 

portion of the system will almost never contain the actual Perform responsibilities which is a unique identifier for the 

objects that provide services. These servers are implemented 15 specific operation to be performed by an agent. The agent is 

on top of DCE/Encina® middleware. As such, they are a server capable of performing the activity. Tasks are respon- 

capable of either receiving remote procedure calls (to inter- sible for failover processors, which are a list of operations to 

faces exposed through the IDL) or reading requests from perform in the case of failure based on return conditions 

queues (Encinal RQS). from executing an activity. 

Services in the AMR Server 15 are triggered by both RPC 20 The activity management subsystem 146 acts as a work- 
calls and queue-fed requests, depending on the nature of the fl ow manager within the AMR Server 15. It is an engine that 
service. Services that access an object in the database and controls business events and contains a knowledge base of 
return some attribute or that immediately answer a question, business rules that are domain specific. It acts in concert 
are triggered synchronously via RPC. Services that carry out w i tn the Transaction Manager (TM) to coordinate higher 
long operations (such as mapping a list of values) are 25 leyel business events such as watching and acting on sched- 
triggered asynchronously via a queued message through ule dependencies within the unit or controlling an event with 
RQS. Some objects may be designed to behave both asyn- a legacy system. 

chronously and synchronously for different methods. M example of a controlled legacy event would be a case 
Referring again to FIG. 4, the various subsystems illus- ^ where the Billing System requests a route to be read within 
trated therein will now be described in detail beginning with three days. The application would request a workflow called, 
the Infrastructure Subsystems. for example, a ReadRoute. The Work Flow Manager (WFM) 
The Activity Management Subsystem 146 houses services uses a dictionary of predefined workflows to determine the 
that invoke and manage Activity Plans. As much as possible, prerequisites for the business flow and all required opera- 
business logic is abstracted away from the service level into 35 tions that comprise the workflow. Each of the operations in 
Activity Plans (to be discussed below). The services are the workflow are autonomous but operating either serialized 
reduced to finite business objects that accomplish a single or in tandem with other operations. Each operation performs 
task or service for the system, usually on behalf of a larger some atomic unit of work (or another WF) in the system and 
grained Activity Plan. As noted above, the Activity Plans reports its success or failure back to the WFM. Each 
may be thought of as a list of tasks or operations that are AQ operation can have failover clauses that allow for error 
performed to complete a business unit of work. The tasks recovery or cleanup. 

themselves do not perform the work, but simply invoke a i n short, the business rules used by the WFM are prefer- 

system service for its task and have information delivered ably the primary mechanism for building functionality in the 

and returned. AMR server 15. Little to no changes should need to be made 

Each operation may have nested failover, undo, and final 45 in the general application set. Each of the systems within the 

commit operations defined. AMR Server 15 responds to messages sent by operations. 

The Activity Plan is a decision tree of these operations All intra-system data is communicated via objects to ease 

along with contextual information carried for the flow and state maintenance. Each operation is checkpointed or stored 

available to each operation. The Activity Plan also defines ^ it sleeps between state changes in the database 120. 

which operations are dependent upon others and thus, which 50 The Activity Management Subsystem 146 Servers will 

operations can run in parallel. Services within the activity now be described. In order for Activity Plans to flexibly 

dispatcher instantiate (start) an Activity Plan, negotiate control system actions, the system is modeled and imple- 

responses and events for Activity Plans, and monitor the mented as a cooperating set of medium to low-level services, 

current status of all Activity Plans in progress. Activity Plans The services are grouped and serialized to perform business 

themselves are scripted outside the coding environment and 55 operations. The grouping and control of the service execu- 

are easily modified to tailor the AMR Server 15 for a tion (to accomplish a specific high-level business task) is the 

particular clients business requirements. Thus, the business job of the Activity Plan object. 

requirements may be easily changed without re -coding the Activity Plan instances are named, for example, by the 

underlying services and objects. The decision process for business unit of work they accomplish and contain an 

guiding execution is controlled by a directed graph of 60 ordered list of tasks that interact with individual services in 

business logic encapsulated in each Activity Plan. The the system. Task instances are named for the service they 

Activity Plan object represents^ state machine that is invoke and know their prerequisites and possible alternate 

self-directed. The dispatcher simply provides the Activity cases in the event of service failure. To support the execution 

Plan objects an environment in which to execute. of business logic through Activity Plans, a support structure 

The tasks have the following responsibilities. The first is 65 for building, dispatching, logging, monitoring and routing 

task sequencing, which determines which tasks can be run in are assembled. This Subsystem consists of a set of five 

parallel vs. serial. The second responsibility is blackboard servers to perform these tasks. They are illustrated in FIG. 
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3 as the Activity Plan Builder 1464, Dispatcher Panel 146a, 
Dispatcher Brain 1466, Dispatcher Storage Manager 146e, 
and Activity Plan Monitor 146c. The servers will now be 
described. The Dispatcher Panel 146a, Dispatcher Brain 
1466 and the blackboard object comprise the Activity Plan 
Dispatcher. 

The Activity Plan Builder 1464 is provided because 
Activity Plans are not useful objects immediately after 
instantiation. They are constructed and passivated for later 
use because Activity Plans are the objects that manage a set 
of tasks to perform a unit of business work. In addition, the 
Activity Plan object itself is simply a manager and container 
for the tasks that get the work done. An ordered collection 
of tasks are constructed and assigned to the Activity Plan 
before it is useful. 

The tasks use the data-exchange object Blackboard, 
which is initialized prior to use. To accomplish this, a tool 
is used to build and manage a dictionary of useful tasks, 
initialize blackboard slots, and assemble Activity Plans. The 
Blackboard object provides methods for creating, accessing, 



sible from the main screen shown in FIG. 29. In this 
example, a ModifyMeter workflow is illustrated with three 
main paths of execution. The first is a Normal path (STS_ 
NORMAL) which translates into a simple update in the 
s database 120. The second is a Move to Non-communicative 
(STS_MOVE„TO__NONCOMMUNICATIVE), which 
lists required tasks that must complete in order to success- 
fully run workflow. The third is a Move to Communicative 
(STS_MOVE„TO_COMMUNICATIVE), which lists 
10 required tasks that must complete in order to successfully 
run workflow. Traversing of various paths (decisions) is 
based on statuses returned at each individual decision point. 
If each task within a workflow completes successfully, the 
final branch returns to the AddUpdateMeterAliases task at 
15 the end of the first decision tree. 

FIG. 31 shows how a particular Task from the main screen 
of FIG. 29 can be modified to execute, undo, or finalize an 
operation. In an undo, the operation reverts to a previous 
task and a previous slate in order to resolve failure condi- 



updating and deleting blackboards and slot contents within 20 tions. Finalizing an operation performs clean-up operations 



blackboards. All blackboards are stored as a streamed object 
(blob) keyed by a unique identifier. When used in conjunc- 
tion with Activity Plans, the unique identifier matches the 
Activity Plan ID with its associated Activity Plan. When 
used for Activity Plans, the blackboard object has predefined 25 
slots required to communicate information among the vari- 
ous Activity Plan tasks. Each task in an Activity Plan 
retrieves inputs from predetermined blackboard slots, and 
places outputs into other predetermined slots. The black- 
board is stored in another persistent store labeled with the 30 
name of the Activity Plan. An Activity Plan object is built 
with the same name as the blackboard's, describing the 
business unit of work to perform. The user then uses the 
builder to populate the named Activity Plan with the 
required tasks. 35 

The Activity Plan Builder 146a* is a developer tool com- 
prising a front-end graphical user interface (GUI), 
controller, and domain objects capable of being stored 
persistently and used by the Dispatcher. The Builder allows 



for any operation that was initiated in a task by, e.g., deleting 
files, etc. 

FIG. 32 illustrates how an operation can be modified. The 
following fields are used in the modification: 
Name — Name of the Operation; 

Queue Name — Queue assigned to Manager (Server) 

responsible for the operation; 
Interface Name — DCE Interface that contains the method 

for the operation; 
Service Name — Method used for the Operation; 
Return Queue Name — Queue name for return results of 

operation; 

Return Interface Name — DCE Interface for return opera- 
tion; and 

Return Service Name — Method used for the Return 
Operation. 

FIG. 33 illustrates the slot names within the blackboard 
object that contain the specific value types used to execute 



for ease of constructing tasks and storing them in a dictio- 40 the operations, 

nary for easy insertion into Activity Plans. In the same The Dispatcher Panel (DPanel) 146a instantiates Activity 

manner, Activity Plans should be constructed through the Plans by name and initiates processing. This server handles 

Builder 146a* by selecting tasks from the dictionary, vali- requests for starting Activity Plans and fields requests for 

dating that static prerequisites are fulfilled, and inserting into current status and obtaining results from completed Activity 

the list of tasks contained by the Activity Plan. All Activity 45 pi ans . DPanel 146a has an API used by requestors to begin 

Plans are stored in a dictionary used by the dispatcher to Activity Plans and to receive results of finished Activity 

copy into execution upon request. The Builder 146d is used Plans. DPanel 146a may also be called to inquire as to the 

in the development cycle to instantiate task objects that will state of a Activity Plan. All DPanel 146a calls are synchro - 

be used in one or more Activity Plans. The builder stores nous . By request, DPanel 146a instantiates a named Activity 

tasks in a persistent dictionary by the name of the task. The 50 pi an f r0 m the Activity Plan storage area, along with its 



builder 146*/ also prepares a blackboard object for the 
Activity Plan. Preparation of the blackboard is a matter of 
predefining slot names and initializing values. The builder 
146a* is also an editor. It is capable of easily allowing the 
user to reference a stored task, blackboard, or Activity Plan 
and change its contents- 
Referring to FIG. 29, there is illustrated the main screen 
of the activity plan builder 146o\ As illustrated, the entry 
screen of FIG. 29 provides the user with the capability to 
view, edit and delete existing workflows, tasks and opera- 
tions in addition to creating new ones. The attributes for each 
workflow, task, and operation are listed beside each item. As 
can be seen from the Workflows illustrated in the top panel, 
the workflow attributes contain tasks (e.g., the Modify Me - 
terSave workflow contains the task ModifyMeter). 

FIG. 30 is a graphical representation of the various paths 
available for that particular workflow. This screen is acces- 



associated Blackboard, both with a unique identifier but 
does not run it. Activity Plans are instantiated and passivated 
using the Dispatcher Storage Manager 146e, keyed by 
Activity Plan identifier. After passivation of the new 
55 instance in the active Activity Plan area, DPanel 146a sends 
a message through RQS to DBrain 146b (described below) 
using the Activity Plan identifier. DPanel 146a can then 
process requests for status or results. 

Activity Plans themselves are instantiated objects, and 
60 outside of a process space (except in CORB A environments) 
are unable to receive messages themselves. Therefore, they 
are invoked and managed by a process. In the case of a DCE 
environment 112, a RPC/Queue server receives and dis- 
patches all communication between other system objects 
65 and the Activity Plan(s). This server is called a Dispatcher 
Brain (DBrain) 146ft, which runs Activity Plans and handles 
responses from other servers sent to active Activity Plans. 
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DBrain 1466 is messaged primarily through the RQS server. The abject model for schedules may have, e.g., a Schedu- 

The sole function of DBrain 1466 is to run Activity Plans leTask class at the top. The ScheduleTask class handles any 

and route responses from other servers to an appropriate external schedules from the business world. A subclass of 

Activity Plan where tasks within an Activity Plan (run in the ScheduleTask class may be defined that handles the 

DBrain's 1466 process space) send queued messages to s detailed entities that contain data for those schedules (e.g., 

other servers. Individual plans may receive priority in acti- metcrs 60 , accounts, etc.) A schedule has several aspects, 

vation based on dynamically set priorities During u>> whal t0 do> when l0 do it> whal objects t0 fonn tne 

processing Activity Plans are passivated when dependen- action ^ and wh ^ action is bc - formed> ^ 

cies prohibit the next task to run and can be re-ac ivated by ScheduleTask object may ^nttm two component objects, 

the DBrain 1466 when the dependent task(s) complete upon ^ ScheduleEvent ^ repr esents what to do, and Schedu- 

receipt of an event notification (Concern Manager 136), and T t . . t , , , . t ™ t ' t 

when Activity Plans mature (i.e., timer expiration). Ie ^f , that 7 resents wl > en t0 do lL ™ e set of ff^ on 

DBrain 1466 is a vendor of special events called Activity whlch to Perform operations may be represented by an 

Plan state changes. The Concern Manager 136 has a corre- ™? U ™ ^ a Me * rGrou P ^ject. 

sponding special interface for requesters to request state In AMR Server 15, a schedule may exist, for example, 

change information by Activity Plan identity, either a spe- 15 because data is to be exported to a utility, or because data is 

cific instance of an Activity Plan, or all Activity Plans with t0 be made available in the AMR database 120. The sched- 

a given name. The special events DBrain 1466 can vend are uler 138 may also handle complex timed execution of other 

Activity Plan Start, Abort and Finish. DBrain 1466 is operations, or may simply indicate the expected arrival of 

responsible for both logging the operations and parameters data from a supplier. In the latter case, there is no expected 

of an Activity Plan and for debugging. As each task begins 20 action for AMR. It is noted that the AMR Server 15 keeps 

and ends, a log entry is written. The log entry contains the receive schedules because the AMR Server 15 maintains 

Activity Plan state and blackboard contents (in their entirety what has been given to the suppliers, and because these 

or selectively) at each step. schedules represent a constraint on the start times of related 

The Dispatcher Storage Manager (DStorageMgr) 146e is AMR actions, 

used to control access (add, update, read, etc.) to the 25 Referring again to FIG. 4, the Scheduler Subsystem 138 

persistent Activity Plans. The DStorageMgr 146e is used has two main servers, the Schedule Manager 1386 and the 

concurrently by the Dispatcher Brain 1466 and the Monitor Scheduler 138a. The Scheduler 138a and Schedule Manager 

to prevent collisions while accessing the Activity Plans. The 1386 interact primarily with each other, the database 120, 

DBrain 1466 server uses the storage manager to maintain the the Activity Management system 146, and an Alarm service 

activity state persistently across system shutdowns and 30 134. The Schedule Manager server 1386 handles the 

Dispatcher failures. creation, updating, and retrieval of schedules to and from the 

Many Activity Plans can be active in the system at a time, database. The Schedule Manager 1386 preferably utilizes 

and may operate for hours or days. It is important to be able Data Access Object (DAO) proxies (to be discussed below) 

to monitor the state or status of any and all Activity Plans. to interact with the Schedule Implementation Server of the 

The Activity Plan Monitor (APM) 146c shows a user the 35 DAO Subsystem 102 to perform all database operations, 

state of any Activity Plan by name, or by selection. The Activity Plans and other subsystems that create and use 

monitor 146c does not examine the log but only knows the schedules will interact with the Schedule Manager 1386. 

current state of the Activity Plan as it is represented in the Additional server processes that implement distributed 

database. It monitors the state of active Activity Plans and , objects for the schedules may supplement the Schedule 

allows examination of completed and aborted Activity Plans 40 Manager 1386. 

from the Activity Plan Archive. The other aspect of the scheduling system is the Scheduler 

Referring again to FIG. 4, a Scheduler Subsystem 138 server 138a, which is responsible for starting the execution 

manages the building and execution of schedules for the of scheduled activities. The Scheduler 138a retrieves sched- 

AMR Server 15, Schedules are used to control the time- ules through the Schedule Manager 1386 and organizes 

based execution of work within the AMR Server 15. Sched- 45 plans of execution. At appropriate times, the Scheduler 138a 

ules can be recurring, specified, start time- activated, or finish initiates Activity Plans to perform the scheduled operations, 

time -act ivated. The Scheduling Subsystem 138 provides a The major incoming stimuli to Scheduler 138a are notices 

single point of database access for creating, retrieving, and from the Schedule Manager 1386 that schedules have 

updating of schedules. In addition, the Scheduling Sub- changed, and alarm calls from the Alarm Subsystem 134. 

system 138 executes scheduled activities at the proper time, 50 Outgoing stimuli are all Activity Plans. The Scheduler 138a 

and optimizes the execution of scheduled activities to avoid also saves some private persistent objects in the database 

conflicts, missed deadlines, and redundant work. The Sched- 120. 

uling Subsystem 138 is provided to accommodate changing The Scheduler 138a server uses the schedules supplied by 

business requirements. It also maintains portability of core the Schedule Manager 1386 to build and execute activity 

objects so that components can be shared with the Sched- 55 plans that drive data collection and export actions. Most 

uling Subsystem 138 in the Supplier System 148. commonly used activity plans are built to schedule the 

Schedules within the AMR Server 15 do not perform the generation of billing reports and other resource intensive 

work; instead, the schedules control the activation of the tasks that must complete within a certain window of time, 

work. As noted above, the work within the AMR Server 15 The Scheduler 138a obtains the average time to process 

is typically controlled by an Activity Plan that is initiated by 60 schedule items, and then determines a number of jobs 

the Scheduling Subsystem 138. Schedules in the AMR scheduled for a given work plan. The Scheduler 138a adjusts 

domain are used lo control the delivery of data from sup- estimates appropriately to schedule a job to begin with a 

pliers to the AMR Server 15 based upon business activities starting time and starting event so that the job can complete 

such as billing export or other data export from the AMR within the deadline window. 

Server 15. Schedules also control other tasks like the loading 65 A constraint on the Scheduler 138a is the need to adjust 

of the Output Staging Database 122 (FIG. 3), and report for real world influences that cannot be accurately predicted, 

generation. In order to schedule a job, the Scheduler 138a needs to 
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determine how long it will take. However, the execution 
time can only be estimated at best; it will change from day 
to day and likely will change as the number of associated 
meters 60 changes. The execution time will also vary based 
on how heavily loaded the AMR Server 15 is. If a new 
schedule is added that executes at the same time as an 
existing schedule, times need to be adjusted to account for 
the load. Important AMR schedules are constrained by 
matching schedules with the supplier, for example, the AMR 
Server 15 cannot start exporting data until the data has 
reached AMR 10. Therefore, the scheduler 138a allocates 
some room when creating supplier schedules, and new 
schedules will have to defer to seniority for choice execution 
times. 

The Scheduler 138a contains several heuristic-tuning 
parameters for adjusting estimated execution times. The 
parameters are set and changed by the configuration file 
interface used by AMR Server 15. The core classes imple- 
menting the Scheduler 138a are designed to be generic, and 
independent of the application domain and of the imple- 
mentation platform. 

The Scheduler 138a may use several important classes to 
build and execute activity plans. For example, ActivityPlan 
may be used, which translates the time specification algo- 
rithms of schedules, describing multiple executions, into 
specific jobs with specific start times. In order to keep the 
scheduling code portable, there is provided three classes that 
isolate system dependencies, the Schedule Builder, Schedule 
View, and Work Plan Agent. The process operates as fol- 
lows. The Scheduler class implements an Encina® 106 
interface. The interface then makes method calls to the 
ScheduleBuilder class, which should be platform- 
independent. ScheduleBuilder uses a Schedule View object 
to retrieve and filter the schedules. Database access depen- 
dencies are preferably handled by Schedule View and kept 
transparent to ScheduleBuilder. Once the ActivityPlan is 
constructed, ScheduleBuilder hands the ActivityPlan to an 
Activity PlanAgent for execution. The agent handles persis- 
tent storage for the plan, and the details of setting and 
responding to alarms and initiating the actions. 

FIG. 5 illustrates the relationship of a delivery schedule 
162/32 to the Scheduler Subsystem 138. The delivery sched- 
ule 162132 notifies the supplier 30 when to deliver data to 
the AMR Server 15 in a recurring manner. The delivery 
schedule 162/32 is owned by the AMR Server 15 and is the 
consolidated schedule of billing and availability schedules 
supplied by the utility. The billing schedule 154 determines 
the timing of data delivery from the AMR Server 15 to the 
utility for billing. The availability schedule 156 notifies the 
AMR Server 15 when to make the reading data available (or 
visible) to the utility. Both billing 154 and availability 156 
schedules are created by the utility; however, the AMR 
Server 15 will keep the schedules in its database. The AMR 
Server 15 derives the delivery schedule 162/32 by taking the 
most restrictive timing from the billing 154 and availability 
156 schedules. For example, if the billing schedule 154 is 
once per month (the last day of the month), and the avail- 
ability schedule 156 is daily (for increased customer 
service), the AMR Server 15 will choose a daily delivery 
schedule 162/32 in order to meet billing and availability 
requirements. 

A collection schedule 34 determines when to collect data 
and what type of data to collect. The AMR Server 15 
provides the supplier with collection component information 
164, i.e., the collection type and the load profile interval. The 
collection component 164 is based upon the rate 158 and 
other data requirements 160 (e.g., power quality) supplied 



by the utility. The AMR Server 15 does not inform the 
supplier of the timing of data collection since it is assumed 
that the supplier has a superior understanding of the com- 
munication network and other constraints. It is also noted 

S that the delivery schedule 162/32 from the AMR Server 15 
should be used to derive the collection schedule 34. 

Schedules may be specialized into two types: Delivery 
Schedules and Receiving Schedules. Delivery Schedules 
specify when the AMR Server 15 is to deliver the data for 

10 the grouped meters 60 to external Application Systems. 
Billing schedules and data export schedules are examples of 
Delivery Schedules. Receiving Schedules specify when the 
data is to be received from the Communication Servers 30 
(suppliers). Receiving Schedules are derived by the AMR 

15 Scheduling Subsystem from Delivery Schedules. 

The AMR Server 15 preferably uses several data struc- 
tures to transfer data and schedule/collection information 
between the AMR Server 15 and Communication Servers 
30, Hie structures encapsulate the data required by the 

20 supplier API to allow for maximum flexibility and future 
expansion. 

Referring again to FIG. 4, there is shown the Alarm 
Subsystem 134. The Alarm subsystem 134 receives requests 
for timed messages. The Alarm Subsystem 134 maintains a 

25 list of wake-ups for any requester in the system. The 
wake -up is stored with a message to send back to the 
requester when predetermined time expires. Activity Plans 
and the Scheduler Subsystem 138 most frequently request 
the services of the Alarm Subsystem 134. 

30 The Alarm Subsystem 134 is comprised of a single server, 
the Alarm Server 134a. The Alarm Server 134a is designed 
as an Encina® server, and will use the Distributes Services 
Framework 104, described above, for its implementation. 
This service is preferably concurrent (multi -threaded) in 

35 order to support multiple clients concurrently in setting and 
processing alarms. The Alarm Server 134a may provide both 
synchronous and asynchronous interfaces to its functions. 
Requests will be transactional, in that if an operation fails for 
whatever reason, it will have no effect. All active Alarms 

40 managed by this service will be stored persistently through 
their life-cycles, which will allow the Alarm Server 134a to 
restore its state in event that it is shut down and restarted 
while active Alarms exist. 

When an Alarm occurs, a callback is made to the sub- 

45 scriber via the asynchronous interface provided by, for 
example, the Queueutil library. If the Alarm was set with any 
information, this will be passed with the SOQueueElement 
back to the subscriber. Optionally, the Alarm Server 134a 
will support a callback mechanism using synchronous RPC 

50 for those subscribers that do not read from a queue. 

Referring again to FIG. 4, the AMR Server 15 is also 
provided with a Concern Management Subsystem 136. The 
Concern Management facility 136 is a set of services 
providing distributed event management for other entities 

55 within the system. The entities may be either a "vendor" 
and/or "requester/' A "vendor" is something that can provide 
notification of an "event," or more generically, something 
that can provide (vend) a particular item. The term "event" 
is used within the written description to mean the occurrence 

60 of one or more specific and well-defined circumstances that 
can be tangibly detected and described. A "requester" is 
something that has an interest or concern in an item that can 
be provided by a vendor, and usually wants to obtain the 
item or in the case of an event, be made aware of its 

65 occurrence. It is noted that a particular client of the Concern 
Management service 136 can be both a vendor and a 
requester, much like a server can also be a client in the RPC 
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world. This design attempts to advantageously solve the To assist in integrating other servers in the system with the 

problem of how to allow requesters to express a concern for Concern Manager 136a, the Distributed Services Frame - 

particular events and vendors and forward these events to work 104 is utilized which allows the developer to mode] the 

any concerned requesters in a distributed system of inter- server as a Vendor and/or Requester and use the respective 

acting services. s number functions just like other server member functions. 

The above implies a process/server/device that tracks Referring again to FIG. 4, a Mapping Subsystem 140 

which vendors can provide specific events and which provides services that allow easy customization of file 

requesters have concerns for these events. The Concern- ?™ te c for . importing data to the 

Manager 136a is a centralized service that coordinates the AMR Server 15. T*e mapping subsystem comprises he 

, . . rpi • i • .i i l , „ canonical mapper 140a, which is included to enhance the 

above-noted interaction. This relieves the burden on vendors 10 cllstoraization ^ f lhe amr Ser ver 15. The purpose of the 

to manage interaction with their requesters. The vendor will Canonical Mapper 140fl is to pro duce maps that can be used 

communicate all event information to a central service. , 0 map information across subdomains. The mapper 

Requesters need not know which vendor(s) can provide assume s that there are at least two subdomains mapped in 

specific events, but only know the event types that can be which t0 transfer information across. Both subdomains are 

provided. From the Requester's perspective, it simply noti- 15 ma pped under the same root domain. The user invokes the 

fies this central service that it is concerned for a particular Mapping tool rather than the Map Builder to create a utility 

event, and the concern manager forwards any occurrences of capable of transforming information from one selected sub- 

this event back to the requester. From the vendor's domain to another. The User Interface is simple. It displays 

standpoint, it simply notifies the central service of any event all maps in two lists and allows the user to select one map 

it can vend, and forwards them on. to the central service 20 from each list. One list represents the subdomain to map data 

when they occur. To be efficient, the central service can from. The other list represents the subdomain to map data to. 

notify a vendor when it needs to begin forwarding events, The Canonical Mapper 140a is preferably implemented in 

since there is no need to forward a specific event if no Smalltalk and hence requires integration into the DCE/ 

requesters are concerned with the event. Encina® environment of the AMR Server 15. To accomplish 

The Concern Management Subsystem 136 is comprised 25 this integration, a Mapping Interface Server 170 provides 
of one server, the Concern Manager 136a. The Concern the DCE/Encina® service requests from the AMR 
Manager 136a is designed as an Encina® server, and uses Subsystems, as shown in FIG. 6. The Mapping Interface 
the Distributed Services Framework 104 as the basis for its Server 170 will interface with the Canonical Mapper Server 
implementation. This service is preferably concurrent using a socket connection. The Mapping interface server 170 
(multi-threaded) in order to support multiple clients concur- 30 will provide a service that allows an AMR Subsystem to 
rently in managing concerns and events. The Concern Man- specify an input file 166, an input map, an output file 168, 
ager 136a will provide both synchronous and asynchronous and an output map. The Mapping interface server 170 will 
interfaces to its functions. Requests will be transactional, in send this request to the Canonical Mapper 140a through the 
that if an operation fails for whatever reason, it will have no socket interface shown in FIG. 6. The input and output maps 
effect. All active Concerns managed by this service will be 35 are derivation trees. Using these maps, the Canonical Map- 
stored persistently through their lifecycles, which will allow per 140a, running in a headless mode, will build a scanner/ 
the Concern Manager 136a to restore its state if it is shut parser for the FROM sub -domain. The Canonical Mapper 
down and restarted while active Concerns exist. 140a will then traverse the input map, parsing the data from 

The Concern Manager 136a is responsible for accepting the input file into a canonical list. After the input map 

concerns from requesters and retaining a mapping of the 40 traversal is complete, a canonical list will exist, populated 

concern. This map contains enough information to make a with the elements from the input sub-domain. Next, the 

callback to the requester at a later time with notification of Canonical Mapper 140a will map from the canonical list to 

the event if it occurs. The Concern Manager 136a provides the output sub-domain by traversing the output map and 

an interface for vendors to register what events they can re -interpreting the corresponding element from the canoni- 

produce and callback information to enable and disable 45 cal list to conform to the new data format. This action creates 

forwarding of these events. the specified output file. 

At startup, all vendors register the events that they can The Canonical Mapper 140a may be configured to accom- 

produce. Vendors register each type of event separately. The modate differing file formats as follows. As noted, the 

vendor will provide the event type and enabling and dis- purpose of the Canonical Mapper 140a is to standardize data 

abling callbacks. Event reporting is considered disabled for 50 formats so that information spanning across different busi- 

a vendor until the Concern Manager 136a receives a concern ness units can be easily converted from one format to 

for a particular event. The Concern Manager 136a then another. 

makes the enable callback to any vendors that have regis- In the detailed description of the canonical mapper 140a, 

tered that they can provide this particular type of event. the following terms are used to describe the features of the 

Whenever this event occurs within the context of an enabled 55 canonical mapper 140a. A "canon" is a tree relating all data 

vendor, the vendor forwards the event to the Concern attributes within a domain of information (e.g., Bill of 

Manager 136a to be handled. Materials). "Canonical elements" are specific parts of a 

On the requester side, requesters register concerns for Canon. A "map" is a data structure that describes the format 

each event separately. The request consists of the event of a particular file in terms of the Canon. A "domain" is a 

name and a callback in the requester to notify it when such 60 collection of data that is semantically consistent (e.g., the 

an event occurs. When a vendor forwards an event matching same data format). "Scanning" is the process of identifying 

a type that a requester is concerned for, the requester is elements of input text. "Parsing" is codifying input text in 

notified via the callback of the event occurrence. Requesters terms of its relationship to the output text. A "token" is an 

explicitly withdraw concerns for events. Callbacks can item added to a value in a file to describe the format of the 

either be provided through the queue of a requester or 65 text. An "action" is a tool for modifying the appearance of 

vendor; or for non-queuing servers (i.e., DCE only/non- a particular file, i.e., an "action" performs operations upon 

Encina), through a synchronous callback interface. text (e.g., add carriage: returns, add quotation marks, etc.) 



04/16/2004, EAST Version: 1.4.1 



US 6,199,068 Bl 



29 



30 



The Canonical Mapper 140a preferably consists of utili- 
ties to create Canons, build Maps, and translate files. A 
Canons utility may be included to create a Canon. The 
Canon is an abstract template or master file that describes a 
general structure for a domain of information. In other 
words, the Canon is a template that describes a general 
format for a domain of information that is to be converted. 
A Canon may be analogized as a tree or an outline that is 
used as a template for the conversion of information. The 



The canonical elements may also be assigned attributes 
that define certain qualities about those elements. For 
example, the attributes may include element types (e.g., 
group and result elements) and modifiers. Group elements 
are elements that contain children (e.g., "Partld" contains 
"ParildValue") and result elements contain a variable piece 
of information that identifies a specific value (e.g., "Partld- 
Value" contains a particular value). A graphical view of the 
Canonical Elements may be derived, as shown in FIG. 28 for 



Canon starts with a root from which other subordinate parts io the Canon "Costing." 

stem. The root of the tree is the name of the Canon, thus the A Maps utility is included to create a map for translating 

root is the parent to every other part of the tree. That parts data from one format to another. Since there may be many 

that are nested or indented within the root are the children. different file formats and applications within a particular 

The Canon is described from top to bottom by the relation- domain, it is desirable that the software be flexible enough 

ships of each part io the other, similar to an outline. Each is to allow users to create customized maps for their particular 

parent contains specific information (i.e., children) and a applications and file formats. These maps are based on the 

child may contain other children. Each child and parent is a Canon for which the data conversion is needed. Maps 

node in the tree. A node that does not contain any children specifically describe formats for the conversion of inform a- 

is a terminal node or leaf node. tion between two applications, i.e., a map is a way to 

Every item in the Canon is a Canonical Element. In order 20 describe the intended output in terms of the Canonical 

for the Canon to function correctly, each element must be Elements. The map does not perform actual converting, but 

defined so that when data is fed through the Canon, the data rather acts as a liaison between the Canon, the input file and 

can be accurately interpreted. The entire domain is described the application used to create the input file. A map is 

in terms of a canonical element that is an abstraction, and essentially a tree that represents a formula for converting a 

then each division or part of that element is subsequently 25 file. Anytime there is a need for data conversion between 

defined in terms of less abstract elements until the entire different applications and there are no existing maps for 

document is defined. Each abstract element ultimately these applications, a map must be created that describes 

resolves to a concrete element. For example, as shown io what the converted information should look like. In other 

FIG. 27, if a user is mapping a domain that is a bill of words, for every two tools that need to communicate with 

material (BOM) document, they select the entire domain 30 each other, there must be a map for each tool. Once maps are 

sample and select the canonical element "BOM". As this created, they can be repeatedly used to convert information 

point, the user has abstractly represented the entire input as between the two applications. 

a "BOM". Then, the user proceeds to identify more detailed Building a map entails selecting each component of the 

abstractions in the input. For example, the user selects the input file and defining its function in terms of the Canon 

domain input comprising all the assemblies and select 35 being used. Attributes about certain Canonical Elements are 

assemblies from the canon. Within that selection, they defined during the process of building a map. For example, 



further sub-select a single occurrence describing an assem- 
bly and map it to the canonical element "Assembly". Map- 
ping proceeds in this manner until all discreet elements of 
the input have been mapped to the canon. 

Relationships exist when a domain contains data that is 
dependent upon other data in the domain. For example, a 
domain input describing a part, wherein a part has a plurality 
of attributes. The word "has" infers a relationship, i.e., the 



group elements may have modifiers defined for them. A 
modifier is a conditional statement that further defines its 
function. The modifiers may indicate that a group element is 
40 not required, indicate that the group element appears more 
than once, indicate that the group contains a series of results 
that are grouped within that element, or indicate that the 
element is required. In addition to modifiers, identifier may 
be included for constant information within the file. The 



part may include a part identifier, material identifier and a 45 identifiers may be used to identify a Result element for a 



parent identifier. 

The domain may be mapped 
following relationships: 
♦Parts (Group) 

+Part (Group, isRepeating) 
+Partldentity (Group) 
PartldTag (Id) 
PartldResult (Result) 
+Materialldentity (Group, is Optional) 
MaterialldTag (Id) 
MaterialResult (Result) 
+Parenlldentity (Group) 
ParentldTag (Id) 
ParentResult (Result) 



to the canon with the 



particular piece of information. An exemplary identifier may 
be an order number for a BOM. 

Tokens and actions are defined in the maps utility. The 
token specifies the format of the results (i.e., values) in the 
50 map. Tokens are defined because they define specific values 
that change depending on the input text. Actions structure 
the appearance of certain parts of the file. For example, a 
carriage return action instructs the mapper to insert a car- 
riage return at a particular point in a file. Two types of 
55 actions may be performed, Canon Actions and Output 
Actions. The Canon Actions are performed on the input text 
as it is converted to the canonical form (step 202) or when 
any actions are necessary prior to the output map has acted 



on the file (step 204). Once the information has traveled 

As exemplified above, the part may be described as a first 60 through the Output Map, the Output Actions are activated, 

canonical element Parts. This is an abstract element denoted These actions are performed because the file has been 

by its type (i.e., group). The next element nested is Part, changed and may need to be re-interpreted before they can 

which indicates that Parts have a Part. The nesting indicates be displayed correctly. 

a relationship. Part has three relationships, Partldeutity, An Interactive Translator utility is provided to test the 

Materialldentity, and Parentldentity. The user controls how 65 actual translation of a file to be mapped for the conversion 

relationships are formed by selecting a previously mapped process. The Interactive Translator bases the conversion on 

element to add a new relationship. the Canon, the Input Map that was created to describe the 
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conversion of the input text, the Output Map that is used to configServer script to configure all the servers and configure 

describe the output text, and the input text being converted. a location of the config file to reference, additional environ- 

The Interactive Translator then produces an output text file ment variables needed, list of interfaces exported by the 

based on the information provided. server, various switches (-noasync-nodatabase- 

Once a successful translation has been made in the 5 singlethreaded), the Encina® name, and the name of the 

Interactive Translator, then the translation across domains is executable. It is noted that when the AMR Server 15 is 

performed in a Headless Translator. By selecting the appro- implemented and distributed on Sun platforms, the Sun 

priate input map, output map, and input text, the Headless Packaging utility is used. This is the same utility that is used 

Translator performs the conversion to create the translated to distribute Sun software. 

text file. 10 Users of the AMR Server 15 can retrieve logs 176 from 

Thus, the mapping process can be broken down into four the Logging Subsystem 142. The Logs 176 may be used for 

main steps: Creating the Canon (Canons Utility), creating auditing purposes and can support certain standard types of 

the maps for the Canon (Maps Utility), testing the file queries. An example of a typical log requirement is to log the 

conversion (Interactive Translator), and mapping the infor- activation of each invoked Application System API call 

mation from the Input Map to the Output Map (Headless 15 with, for example, the following information: API invoked, 

Translator) to create the converted file. User, Time and Supplied parameters. 

Referring now to FIG. 7, the process of converting a file The Log 176 is internationalized, since users of the 

between two applications (i.e., from one domain to another) system may view its contents. Log messages contain e.g., 

will be described. Using the Maps utility, the input text file the following levels: INFO, WARNING, ERROR, and 

200 is selected. In order for the mapping to be successful, the 20 FATAL. Users may use Tracing 142 to "trace" the execution 

input text 200 is translated to a Canonical Form in accor- of the system to resolve problems. When the tracing com- 

dance with an input map 202. The particular Canonical Form ponent is activated, it will place messages in a specified trace 

of the input text depends on the Input Map 202 that is being file 178. The trace messages have trace categories that can 

used. The text must be transformed into a Canonical Form be controlled by adjusting the trace masks of servers in the 

at step 202 so that the text can be sent to the Output Map 204 25 system. Typical trace categories are defined for 

in a format it can accept. Once the text file has been performance, auditing, function, exception, debugging, and 

converted to its Canonical Form, it is interpreted by the user-defined categories. 

Interactive translator in accordance with the Output Map Tracing is initialized from the system configuration file 

204 that was specifically designed for converting files 174. The default configuration for a delivered system is to 

between the two applications to generate an output text file 30 have tracing disabled. Tracing is only required to track down 

206. The output text file 206 is parsed and translated by the problems that occur in a running system and can be activated 

Headless Translator into a text file 208 that can be printed, at runtime on the entire system or any of the individual 

saved, or placed into a word processing document. servers within the system using the ASADMIN utility 180. 

Referring again to FIG. 4 and FIG. 8, a Log/Trace The ability to specify trace masks for running servers 

Subsystem 142 is provided which is a group of class libraries 35 provides a mechanism to adjust (increase or decrease) the 

available to all servers through the AppServer class. The amount of information traced by the server. Tracing might be 

Log/Trace 142 provides all servers with a common mecha- used when there is a problem with the Supplier Manager 

nism for logging and tracing. Logging and tracing are 148a and a user needs to view the trace messages for 

initialized from a system configuration file 174 that activates function, exception and debugging to understand and isolate 

logging and specifies the default log file 176 destination. 40 the problem. At runtime, the ASADMIN utility 180 may be 

These settings can be modified during runtime by using an used to activate tracing on the Supplier Manager server 

administration utility (ASADMIN 180) provided with the 148a, with a trace mask that enabled these categories 

system. (function, exception, debugging), and a trace file specified 

The ASADMIN utility 180 is a program that allows for the output. By viewing the trace messages output by the 

system level control of servers running the AMR Server 15. 45 Supplier Manager 148a when the problem occurs, the devel- 

The ASADMIN 180 is capable of starting and stopping the oper has much more insight into how the system is reacting, 

servers. In addition, the ASADMIN 180 can modify and Each of the above-described subsystems comprise the 

query system configuration variables. The configuration Infrastructure subsystems of the AMR Server 15. The Appli- 

options (asadmin config) may provide options for reloading cation Subsystems will now be described, also with refer- 

the server's particular configuration file 1726, returning the 50 ence to FIG. 4. 

configuration filename used by the server, setting a variable The AMR Server 15 Graphical User Interface (GUI) 92 

in the server, returning the configuration information by provides users with access to the functionality of the system, 

variable, returning the configuration information by group, The GUI 92 provides a User Interface that is self- 

and retrieving all possible log settings from the server. explanatory and easy to use. For example, the GUI 92 

Several scripts may be used for configuration. A first 55 utilizes the mouse and keyboard input devices and as such 

script (rc.amr) may be written to start or stop all servers. The is not geared towards volumes of data entry. For mass data 

script preferably attempts to start all servers in order of entry, the AMR Application Systems automate mass data 

dependence by the AMR Server 15. A second script entry through the provided DCE 132 and file based inter- 

(conflgServer) may be used to configure an individual faces 128. The GUI 92 is intended for rapid access to the 

Encina® 106 server. The Encina® cell, however, must be 60 functionality for smaller data entry jobs, 

properly configured before this script is executed. After The AMR GLTl 92 preferably runs on Windows NT® 4.0 

configuration of Encina® 106 cell, the configServer script or UNIX workstations and is preferably implemented in a 

may validate the many parameters, configure the server in windowing environment. The GUI 92 provides a user 

Encina® set the interface ACLs, start the server, modify the friendly and intuitive environment for accessing various 

server directory permissions to be more open, and set the 65 AMR activities. The GUI 92 allows user to manually invoke 

queue ACLs. A third script (amrsetup:) may be used to all business system interfaces online, allows user to search 

configure or unconfigure all the AMR servers. It uses the on specific meter/account/rate/event information, provides 
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access to Activity Management System 146c monitor, and notification when none are available, the call will block until 

provides interface to schedules. a new notification arrives (or a timeout occurs), thus pre- 

The GUI 92 is preferably developed in Java™ to provide venting busy polling. The Notification server 92d is prefer- 

platform independence and the capability of remotely run- ably written using straight DCE (without Encina®) and does 

ning as an applet from standard Internet Browsers. The GUI 5 not use the AMR framework. In accordance with an aspect 

92 uses Standard Application System APIs provided by the of the present invention, the AMR Server 15 performs all the 

Utility Interface Subsystem 144 to initiate requests. In order real processing. Therefore, it accepts client requests and 

to connect a Java™ client to the AMR Server 15 through returns data back to the client (either synchronously or 

DCE some technical challenges have to be overcome due to asynchronously) via the Notification server 92cL 

the relative immature state of Java™, The following section io When the GUI client 92a receives a notification that an 

explains the GUI Interface Architecture required to accora- activity plan is complete, the GUI client 92a receives data 

plish this unique connection. passed back in a wait call, or the client 92a may call the 

As shown in FIGS. 4 and 9 below, there are five major Utility Interface 144a, as noted below. The call to the Utility 

''pieces" involved in connecting the Java™ client GUI to the Interface 144a is preferably a RPC call, however, may be 

AMR Server 15. They are; a Client GUI 92a, a DCE is performed by directly accessing the blackboard. In addition, 

Encina® Lightweight Client™ (DE-Light) gateway 92b, the GUI 92 is designed to handle a situation where the client 

Custom gateway server (ConfigUtility) 92c, Custom notifi- 92a terminates. For example, if the client 92a cores, then the 

cation server 92d, and an AMR Server 15 (Utility Interface) server 15 will timeout. If the client 92a shuts down 

144a peacefully, then the Notification server 92a* will call an 

The Client GUI 92a is preferably implemented in Java™ 20 abort. On the other hand, if one of the servers in the AMF, 

and performs all communication using the DE-Light gate- Server 15 terminates, then the client 92a will attempt to 

way 92b. The client 92a provides a "thin" client that is reconnect for a predetermined number of times or period of 

capable of running on a large variety of platforms. The GUI time (e.g., 10 times or 5 minutes). If the server is brought 

92 submits end user requests to the AMR Server 15 and is back up, then the client 92a will reconnect and pending 

responsible for interpreting and displaying any data returned 25 requests, if any, can be reissued. If the server fails to come 

from the AMR Server 15. The GUI 92 is capable of up, then the client 92a will be unable to reconnect and will 

performing a variety of activities related to meter be notified such that the application calling the server can be 

management, such as adding a new meter, installing a meter, closed. 

uninstalling a meter, terminating a meter, modifying a meter, Referring again to FIG. 4, the AMR Server 15 includes 

estimating a meter reading, entering a meter reading 30 Support Services that are a group of Subsystems that accept 

manually, reading a meter, adding a meter to an account, requests, and communicate with systems 90 external to 

removing a meter from an account, adding a rate to a meter, AMR Server 15. The Utility Interface Subsystem 144 is the 

removing a rate from a meter, adding a meter to a data entry point for Application System requests to the AMR 

collection group, removing a meter from a data collection Server 15. All customer requests come in through this 

group, and defining communication parameters for a meter. - 35 Subsystem. Every external business service the AMR Server 

To perform each of the following activities, the user may 15 may be asked to perform is represented by a service API 

click on icons or press a combination of keys to be presented in this interface. The services within the Utility Interface 

with a data entry screen. The data entry screen includes a list 144a have some common features (by using a common set 

of required and optional fields into which information may of services within this Subsystem). When a service API is 

be entered using the keyboard and/or mouse. The DE-Light <io invoked, the accompanying arguments or parameters are 

gateway 92b, available from Transarc™ Corporation, is validated, and translated to a form used within the AMR 

provided to allow the Java™ GUI client 92a to make RPC Server 15. 

calls into Encina® 106 servers. It is used as communications The Utility Interface Subsystem 144 is comprised of a 

middleware to connect the Java™ client 92a to the Encina® single server, the Utility Interface Server 144a, This server 

ConfigUtility server. The DE-Light gateway 92b enables the 45 is an RPC server that provides the DCE only interface for 

Java™ client 92a to make a secure connection to the AMR external Application Systems 50. This server controls access 

Server 15 using the DCE security service. to services within the system by security mechanisms built 

The ConfigUtility server 92c is provided to work around into the messaging layer and translates proprietary data from 

limitations in DE-Light 92b. In particular, it acts as a custom the utility client to a format useful to the AMR Server 15. 

translator between the Java™ client 92a and the AMR 50 The Utility Interface server 144a does not directly accom- 

Server 15. It mainly performs data conversion (such as plish the work requested. The services the utility interface 

serialization) and does not contain any significant applica- provides are "windows" into the system through which work 

tion logic. All RPC calls from the GUI 92 are directed to the requests pass. After necessary mapping/validation of param- 

ConfigUtility server 92c. This server 92c will provide the eters has been completed, these services message the Activ- 

Java™ client 92a with a mechanism to poll for asynchro- 55 it y Dispatcher 146a to invoke an Activity Plan to accomplish 

nous replies from the Utility Interface 144a via a Notifica- the business tasks of the request. All services are synchro - 

tion Server 92a". nous in that they immediately return a result to the requester. 

The Notification server 92a* acts as a queue that allows However the nature of the result differs, based on whether 

clients that cannot handle incoming RPC calls to process the invoked service is interactive, or the initiator of a batch 

asynchronous notifications. The server 92a" assigns a uoique 60 process. 

client ID to each client. Clients then tag their request", to the Interactive services, or those requiring an immediate 

AMR Server 15 with their client ID. The AMR Sevvwr 15 response to the user will wait for the Activity Plan to 

calls the Notification server 92a* when asynchronous complete and return an answer. These types of requests can 

requests are complete and stores any information provided, be quickly satisfied within the system through access to 

including the requesting, client's ID, in a delivery queue. 65 warehoused data. Other services initiate batched background 

Clients execute a simple loop, fetching available notifi :a- work. These services message the Activity Dispatcher Panel 

tions and processing each in turn. If a client tries to fetch a 146a to begin an Activity Plan that will complete at some 
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time in the future. These types of requests are called asyn- protect itself from future change or new systems, 

chronous or deferred requests. When the Utility Interface Specifically, the AMR Server 15 accomplishes this isolation 

144 activates an Activity Plan, it receives the unique Activity by finding the commonalty in the existing systems and 

Plan identifier assigned by the Dispatcher Panel 146a, and defining generic interfaces that will communicate to the 

uses this identifier to register an activity completion concern s AMR Server's 15 Wrappers" for the specific communica- 

with the Concern Manager 136a. tion systeras< the on i y components that wil] change 

The external requester of the work is also immediately over time wfll be the lhird . parly interfaces and how the 

answered with the identity of the Activity Plan. The ^ Server 15 tnose interfaces . amr Scrver 

requester can ater use other services to check on the status can add new tems b bum Wf thal communi . 

of a Activity Plan and/or be notified when a Activity Plan has „ ( , - Tr * T , n v r • ■ 4 . 

1 # j tu a * * * rv . u r> • iacu 10 cate with generic IDL definitions for services inside the 

completed. The Activity Dispatcher Brain 146b commum- amr ^ 1* 

cates to the Concern Manager 136a who in turn notifies all , erver 

interested parties when an activity has finished. When the s y stems can b T c , lreated s j milarl y to ^ ex f te L mal 

Utility Interface Manager 144a receives the Activity Plan communication systems. However, due to the nature of these 

completion notification, it will return the results to the svstems > il * Ukel y thal the tv P e of information that 

requesting client. 35 ^ retrieved will not be compatible with the message-based 

Ibis asynchronous or deferred service requests from architecture of the AMR Server 15. In particular, it is likely 

external systems to the Utility Interface Subsystem can that legacy systems will transmit information via flat files 

provide a client context, which is carried through the AMR which must be parsed into message sends, and conversely, 

Server 15 unmodified, and returned with the corresponding the AMR Server 15 messages will need be collected in 

results. This service allows an external system to create a 20 batches to form flat files for import into the legacy system, 

context identifier meaningful to their application that can be This can best be accomplished by determining the superset 

used to marry the response to the original request. or canon of attributes that will be communicated by the 

In addition, the Utility Interface 144 allows an external legacy systems. The canonical mapper 140a, described 
system to specify in each asynchronous/deferred request, the above, maps legacy specific formats into common formats 
binding information of the RPC server within their system is that have optimized parsers designed for messaging, 
that should receive the results of the request. If the request The Supplier Subsystem 148 houses services that are 
does not provide this binding information, then the RPC specific to how a supplier communicates information; mean- 
server specified as a system-wide default will be used. The ing that there will be separate supplier interfaces for different 
system-wide default RPC server can be set using the con- interface modes (asynchronous/synchronous) with limita- 
figuration file. 30 tions and extensions necessary to support fixed networks, 

Referring to FIGS. 4 and 10, there is illustrated the telephony, etc. The type and capabilities of a supplier are 
Supplier Subsystem 148. The Supplier Subsystem 148 is determined by meter identity. The supplier interface asks 
analogous to the Utility Interface Subsystem 144. It could be suppliers for actions, such as remote disconnect, and stand- 
considered the "Order Fulfillment Center" for the system. ing orders (sample delivery). The interface encapsulates the 
There are two terms used to discuss the systems that provide 35 differences between synchronous and asynchronous forms 
the metering data to the AMR Server 15. The terms "Sup- of interface as well as differences in network types so that 
plier" and "Communication Server" are used interchange- clients of the interface need not know what "type" of 
ably herein. The name "Supplier" is used because the supplier they are interacting with. 

external systems that are communication with the AMR These services are similar to utility interface services in 
Server 15 are not "communication systems" in the normal <io that they perform any required translation of internal key 
computer sense of the word. Rather, they are simply other codification into proprietary formats expected by external 
computer systems that have their own APIs or database suppliers of information. All outgoing requests to suppliers 
formats for retrieving information which is supplied to the are accomplished through Activity Plans (via the Activity 
AMR Server 15. Dispatcher 146a). Services triggered from a supplier will 
From the perspective of the AMR Server 15, a "comm" or 45 begin Activity Plans to accomplish tasks such as requesting 
communications system is one that operates asynchronously information for a group of devices and then moving the 
and delivers its data in a raw (or non-structured) format and results to the Receiving Subsystem lSOo* in the Data Access 
in its own time not the system's (i.e. real or near- real time).. Object Subsystem 150 (discussed below) for processing. 
The external information systems 50 that collect and report Thus, the primary purpose of the Supplier Subsystem 148 
meter information should appear to communicate with the 50 is to provide the AMR Subsystems with secure access to data 
AMR Server 15 in the same manner that the AMR Server 15 collected and stored on any supported Communication 
might communicate with any other information system. Server 30. To accomplish this, the SupplierMgr 148a, Sup- 
With this in mind, it is preferable that the AMR Server 15 plierOutgoing 148c, and Supplied ncoming 148d servers 
communicate with an external system the same way that the interact with each other, AMR business objects, the Activity 
internal systems or components within the AMR Server 15 55 Management Subsystem 146, and the AMR Event services 
communicate. For example, a message model can use a (see FIG. 4). In addition, the SupplierOutgoing 148c and 
broker to resolve location and an IDL to define interfaces. Supplierlncoming 148a* servers are designed to interact with 
Accordingly, the AMR Server 15 uses this same model to specific types of supported Communication Servers 30. The 
communicate with external systems. The AMR Server 15 Supplier Manager 148a is used within the Supplier sub- 
views each of the external systems by "type" and list 60 system 148 to hide the differences in communication sys- 
attributes or types of information that it will require as input, tems. From the AMR service level, all communications 
and the type of information that it will supply as output. The systems appear identical as viewed from the Supplier Inter- 
AMR Server 15 then is able to find commonalty between face. 

systems and define a high level of interface descriptions that It is also the purpose of the Supplier Subsystem 148 to 

will work with each type. 65 provide a single point of secure access for AMR Subsystems 

The AMR Server 15 maintains the interface to external 100 to all supported meter Communication Servers 30. The 

systems abstracted as far out of the system as possible to appropriate interface is chosen by the Supplier Subsystem 
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148, thus shielding other AMN. Subsystems from the intri- 
cacies of binding to a specific interface. The Supplier 
Subsystem 148 also provides a single point of secure access 
for all supported meter Communication Servers 30 to ser- 
vices provided by the AMR Server 15. Further, the Supplier S 
Subsystem 148 encapsulates the differences between Com- 
munication Server 30 interfaces, as well as differences in 
network types, so that AMR Subsystems need not know 
what "type" of supplier with which they are interacting. The 
Supplier Subsystem 148 support both synchronous and io 
asynchronous Communication Server 30 interfaces, per- 
forms required data transfer between internal AMR business 
objects and the data structures supported in the Supplier API, 
and performs any required translation of internal key codi- 
fication into proprietary formats expected by external sup- 15 
pliers of information. 

The primary constraints on Communication Server 30 
access are security considerations and transaction control. 
Security considerations are addressed by DCE security 
services. Transaction control internal to the supplier Sub- 20 
system and during interactions with other AMR services is 
provided by Encina® 106. 

For Communication Servers 30 conforming to the syn- 
chronous model (FIG. 11 described below), the workflow 
Subsystem interacts with the SupplierMgr 148a through 25 
RQS and data is passed via business object proxies passi- 
vated in an AMR Blackboard object. Based on information 
obtained from the business object proxies, the SupplierMgr 
148a can route the request, along with the required business 
object proxies, to the appropriate SupplierOutgoing 148c 30 
server. The SupplierOutgoing server 148c translates the data 
as required by the Supplier API and forwards the request to 
the Communication Server 30. Return information is then 
used to update AMR business objects. Service requests from 
Communication Servers 30 are forwarded by the Supplier- 35 
Incoming server to a DockControl 148b interface, which 
then starts a workflow to perform the required tasks. 

The asynchronous Communication Server 30 model 
(FIGS. 12 A and 12 B described below) is similar to the 
synchronous model with the exception that the requesting ao 
activity does not wait for the response from the supplier 
Subsystem. The result is returned at a later time though a 
Supplierlncoming server 148a* and can be tied to the original 
request using the AMRContext passed to the Communica- 
tion Server 30 with the original request and returned with the 45 
response. 

Referring to FIG. 11, synchronous requests (from the 
Application System) return their specific outputs directly. 
They also provide the status of the request and AMR context 
information that can be used to retrieve information about it 50 
from the system log. Synchronous requests usually provide 
the fastest execution of an AMR service. However, they tie 
up the requesting thread and user window (if any) until they 
are done. 

FIG. 12 A illustrates the process of an asynchronous 55 
request. Requests that may require data from the commu- 
nications servers or physical meters 60 will be made through 
the asynchronous mode because they can take relatively 
longer to carry out. Requests that may return a large volume 
of data should also be made through the asynchronous mode. <so 
RPC through DCE does not support true asynchronous 
requests, so the AMR Server 15 will realize asynchronous 
requests by generating a separate RPC call to inform the 
Application System when the request is complete. Asyn- 
chronous requests (from the Application System) return the 65 
status of the request start-up, and the AMR context 
(reference) of the requesting RPC call. The response 
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(message) provides the overall status of the service. The 
response contains either the output data directly or the 
output locations. The Application System may also provide 
its own context information returned with the response so 
that the Application System can associate the appropriate 
request with its response. 

Referring to FIG. 12B, Asynchronous Notifications will 
now be described. The AMR Server 15 will generate some 
scheduled services. For example, it generates services peri- 
odically to store and collect meter readings for each billing 
schedule. The AMR Server 15 will notify the Application 
System when these services are complete by invoking an 
RPC call to the Utility. The Notification call will contain the 
outputs, and the AMR context (reference) of the service. 

The Supplier Subsystem 148 is composed of three actual 
servers, a Supplier Manager 148a, a Supplier Outgoing 
148c, and a Supplier Incoming 148a 1 , and one logical server 
(not shown), and a Dock Control 148£>. 

The Supplier Manager Server 148a is the primary point of 
access for other AMR Subsystems. As shown in FIG. 4, the 
Supplier Manager 148a serves as the interface between the 
AMR Activity Management Subsystem 146 and the specific 
AMR Server 15 handling communication with Communi- 
cation Servers 30. It routes meter service requests from 
AMR. services to the AMR Outgoing service 148c respon- 
sible for interfacing with the Communication Server 30 
handling the requests for the specified meter. The Supplier 
Manager 148a also manages the delivery schedules and 
collection component distribution to the Communication 
Servers 30 (FIG. 5). For example, when an AMR schedule 
for data (billing schedule, data collection group schedule, 
etc.) is added or deleted, it is the responsibility of the 
Supplier Manager 148a to determine which Communication 
Server 30 should have the delivery schedule added or 
deleted based upon the meters 60 that the Communication 
Server 30 supports. 

It is noted that the Communications server network layer 
preferably supports various network technologies without 
changing application code. A successful communications 
architecture should assure that network specific instructions 
are pushed as low as possible, and common communications 
instructions are elevated to assure minimal amounts of new 
code development with each different communications envi- 
ronment. 

There may be multiple Supplier Outgoing Servers 148c 
running in the AMR Server 15. As its name implies, the 
Supplier Outgoing Server 148c handles the communication 
from the AMR Server 15 to the communication servers). In 
general, each Supplier Outgoing Server 148c is responsible 
for a particular type of Communication Server 30 (not a 
particular instance). There may be a one-to-many relation- 
ship of the Supplier Outgoing Server to communication 
servers 30. 

The Supplier Outgoing Server 148c shown in FIG. 4 acts 
as an Encina® 106 server to the Supplier Manager 148a and 
as a RPC client to the Communication Server 30, assuming 
the Communication Server 30 supports DCE. The AMR 
Server 15 publishes a Standard DCE API for interfacing 
with Communication Servers 30. If a Communication 
Server 30 does not support DCE, but provides some other 
interface, then it is the job of the Supplier Outgoing to bridge 
this interface gap and hide the implementation details of this 
custom interface from the other AMR Subsystems. 

The Supplier Outgoing server 148c is responsible for the 
data transfer between the internal AMR business objects and 
the data structures and files supported in the Standard 
Supplier API (discussed below), or to customized data 
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structures for different types of Communication Servers 30. 
In general, it is assumed that a customized Supplier Outgo- 
ing Server 148c will be required for each different type of 
Communication Server 30 supported by the AMR Server 15. 

There may be multiple Supplier Incoming Servers 148d 5 
running in the AMR Server 15. As its name implies, the 
Supplier Incoming Server 14Sd handles the communication 
from the communication servers) to the AMR Server 15. In 
general, each Supplier Incoming Server 148d is responsible 
for a particular type of Communication Server 30 (not a 
particular instance of a communication server). In the spe- 
cific case of the RCS-250 communication server, there will 
be a one-for-one relationship between a Supplier Incoming 
Server 148^ and the communication server. 

The Supplier Incoming Server 148d shown in FIG. 4 acts 
as a Encina® 106 client of Dock Control 1486 and as a RPC 15 
server to the communication server 30, assuming the Com- 
munication Server 30 supports DCE. The AMR Server 15 
publishes a Standard DCE API for interfacing with Com- 
munication Servers 30. The AMR Server 15 has a designed 
flexibility regarding how meter (and other) data suppliers 20 
communicate information. It is preferable to keep the AMR 
interface for receiving information is as open as possible as 
some suppliers will be sophisticated and make use of the 
RPC interface while others may push (or pull) flat files into 
our file system. Other possibilities include, but are not 25 
limited to, remote table reads and reading remote message 
queues. 

One important note is that Supplier Incoming 148d does 
not retrieve information directly from devices and is not a 
data supplier If the AMR Server 15 is required to read data 30 
from devices, a separate (sub)system acting as a supplier 
needs to be added. If a Communication Server 30 does not 
support DCE 112, but provides some other interface, then it 
is the job of the Supplier Incoming \4Sd to bridge this 
interface gap and hide the implementation details of this 35 
custom interface from the other AMR Subsystems. The 
Supplier Incoming server 148d is responsible for the data 
transfer between the external data structures into internal 
AMR business objects. In general, it is assumed that a 
customized Supplier Incoming Server 148d will be required 40 
for each different type of Communication Server 30 sup- 
ported by the AMR Server 15. 

As shown in FIG. 4, the Dock Control 148b is a logical 
server, (actually contained within the same process space as 
the Supplier Incoming Server \48d) that interfaces between 45 
the Supplier Incoming Server 148<i and the Activity Man- 
agement Subsystem 146. Dock Control 148b directs incom- 
ing service requests from Communication Servers 30 to the 
activities responsible for servicing the request In some 
situations, Dock Control services I486 are triggered by data 50 
arriving from suppliers, which then directs the work to the 
appropriate receiving point (Receiving Services). Data may 
be sent from suppliers as files moved into a receiving DFS 
directory, an RPC with a reference to a table space, an RPC 
with a reference to a remote file, an RPC containing an 55 
individual update, and an RPC with reference to available 
messages in a supplier queue. 

Dock control 1486 is an object whose API acts as a "traffic 
director." Dock control 1486 begins Activity Plans to handle 
data from suppliers. The differing nature of data (large loads 60 
versus outage messages) requires subhandlers (delegated 
objects) to do the actual work. Thgrefore, dock control 1486 
is simply a hand-off point much like the Utility interface 
144. As discussed above, Dock Control 1486 provides an 
interface for use by the Supplier Incoming Server 148rf. 65 

Referring again to FIG. 4, the Application Subsystems 
also comprise the Data Management Services. The Data 
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Management Services are provided by two Subsystems, a 
Data Access Object Subsystem 150, and an Export Sub- 
system 152. 

The Data Access Object (DAO) Subsystem 150 shown in 
FIG. 4 is the primary Subsystem of the Data Management 
Services. The DAO Subsystem contains Persistence objects 
to manipulate the Oracles database, thus isolating the use of 
the Persistence middleware 108 to a set of specialized 
servers within this Subsystem. The Persistence objects 
(DAOs) are object representations of tables within a rela- 
tional database. Data access objects represent the different 
components of a database. The objects have a hierarchical 
relationship to one another; one type of object or collection 
contains or is contained by another type of object or col- 
lection. The DAO Subsystem 150 is responsible for provid- 
ing the Application Support Services with access to the Data 
Repository 120. This Subsystem simplifies the storage and 
manipulation of collected meter samples. Relationships 
between requesting, storing, retrieving and combining col- 
lected data are understandably complex. 

The DAO subsystem 150 is provided such that application 
developers do not need to have an understanding of the 
relationships of the complex data in the system in order to 
access the data. Successive layers of encapsulation isolate 
the complexity of dealing with the complex, data of the 
system. To this end, proxy objects are used to encapsulate 
the relationships and behavior of this data. These proxy 
objects are collectively called "Business Objects." The 
proxy objects are typically utilized by Manager Servers, as 
well as by other Application Support Services. For instance, 
the data and behavior of rate information is complex. This 
complexity is hidden within a set of rate business objects 
(e.g., Rate, MelerRate, RateComponent, at 
Me asurementCap ability, etc.) which have a higher level 
interface called a "Rate Manager 1506." 

There are many such business object managers through 
which application developers access business objects or 
perform medium-grained operations. There are successive 
layers of encapsulation that isolate the complexity of dealing 
with the complex data of the system. These layers comprise 
the Data Access Object Framework 102 shown in FIG. 3 and 
discussed below. 

The Distributed Access Object Framework 102 is pro- 
vided to simplify the development of distributed objects in 
the Encina® environment 106. The system can be consid- 
ered as consisting of two main framework components, a 
DO Factory library, which provides a dynamic/runtime inter- 
face for creating server objects in the Encina® environment 
106. and a code generator (genlnterface), which generates 
business objects and proxies. The Distributed Access Object 
Framework 102 advantageously provides an environment 
wherein the creation, deletion and usage of distributed 
business objects are transparent to the user. The Distributed 
Access Object Framework 102 also provides standard meth- 
ods and implementations for all business objects, and hides 
all details of the Persistence 108 data access objects (DAOs), 
DCE communications, DCE datatypes, etc. 

To this end, the Data Access Object Framework 102 
provides proxies, manager servers, and back-end implemen- 
tation servers for the various business objects in the AMR 
Server. 15. FIGS. 14 and 15 show an example of a meter 
object, showing the role of the proxy, a meter manager 
ser/er, and the meter back-end implementation server 150a. 
As aoiod above, proxy objects are mapped to DAOs, which 
in tur:i are object representations of tables within a relational 
databar*e. The logical architecture of the DAOs for the 
various managers and subsystems will now be described. 
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When a manager server invokes one of the client methods 
on a proxy, the proxy will call the back-end implementation 
counterpart to perform the actual work with the associated 
DAOs. The call to the back-end implementation may be 
performed via RPC if the proxy and DAO are not in the same 
process space. The proxies are distributed objects which 
"stand-in" for DAOs in an Encina© Server. DAOs, by their 
nature, cannot be distributed and cached in memory. 
Therefore, proxies represent, or "wrap", their respective 
DAOs from within Encina® servers, while the DAOs reside 
in cache for fast access. In this manner, data and transac- 
tional integrity are maintained in a distributed environment. 
This distribution creates a relative lightweight manager 
server that is responsible for the coordination of various 
proxies to accomplish the requested AMR domain service. It 
also provides an isolation of the Persistence middleware 108 
to the implementation servers. The manager and implemen- 
tation servers (shown together in FIG. 4) can hence be 
distributed across machines if necessary, as the system is 
required to scale up, without sacrificing transaction integrity. 
To be efficient, this framework is developed with an option 
to build the back-end implementation behavior local with 
the manager server. 

FIGS. 13 and 14 show the interaction between manager 
servers, proxies, and implementation servers within the 
DAO Subsystem 150; how other Subsystems can utilize the 
proxies directly to increase efficiency when simple Create, 
Read, Update, Delete, List, and Exists (CRUDLE) types of 
requests are needed; and how exceptions are managed and 
converted into the standard sysStatus object within the DAO 
Subsystem. 

The Meter Manager Server 150a contains a Rate 
BO-Proxy in addition to a Meter BO„Proxy. This is typical 
in the design of all Manager Servers, because the Manager 
Servers are responsible for providing AMR domain services. 
For example, the Meter Manager provides the retrieveR- 
atesForMeter service, which requires that it create a Rate 
Proxy in order to perform "Reads" for the specified meter. 
Each proxy is coupled with a dedicated back-end 
implementation, which in turn is coupled to a dedicated set 
of DAOs (see the Rate Implementation Server 1506 and 
Meter Implementation Server 150a discussed below with 
reference to FIG. 16). 

FIG. 13 additionally shows how the Utility Interface 
Server 144a (an Application Support Service) may directly 
create and utilize proxies. This is the typical usage that any 
Application Support Subsystem can make of the proxies. In 
these cases, the Application Support Subsystem uses the 
wrapped Create, Update, Read, Delete, List and Exist 
(CURDLE) methods, provided by the proxies to perform 
these simple operations against the Implementation Servers 
and the Data Repository 120. In these examples, the AMR 
domain knowledge provided by the Manager Servers is not 
required. 

Although not explicitly shown in FIG. 13, the design also 
supports Implementation Servers that do not have an explicit 
Manager Server like Meter Manager 150a and Rate Man- 
ager 150b. An example of this type of Implementation 
Server is the External Translation Implementation Server. In 
this case, other Manager Servers that need translations from 
this Implementation Servers will create and use the External 
Translation Proxies, whose back-end implementation and 
DAOs reside in the External Translation Implementation 
Server. 

FIG. 13 also shows the exception handling and sysStatus 
conversion performed within the DAO Subsystem 150. The 
primary purpose of the system status (sysStatus) is to drive 
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the activity plan logic. In addition, sysStatus is used for 
information purposes oulside of the AMR Server 15 system. 
Exceptions should not be thrown across a server boundary 
due to the limitations of Encina® exception handling. 

The responsibilities of the Manager/Other Servers (users 
of proxies) are to catch sysStatus exception thrown by 
proxies (for logic control), convert sysStatus exception into 
appropriate sysStatus based on context and return via RPC 
in the status argument or in WFQueueElement statusStruct, 
catch communication exceptions, and catch base exceptions. 
The responsibilities of the Implementation Server is to: 
catch all exceptions, translate to sysStatus and return via 
RPC in status argument, and never re -throws exception 
across server boundary. 

Referring to FIG. 15, there is shown the process per- 
formed each time a method is invoked on a proxy. When the 
client needs to use a distributed object, it calls the construc- 
tor (step 1) on the distributed object. From the client's view, 
this is similar to calling constructors on any object. 
Internally, however, the distributed object/proxy knows that 
it is named DOFactory, and calls a Create (step 2) on the 
factory. This results in the Create RPC (step 3) to the 
DOFactorylnterface on the server. The Create routine imple- 
mentation on the server calls (step 4) the constructor on the 
DistributedObjectlnterface using ObjectStore and Per- 
former. The RPC then queries the interface object for its 
Encina® reference and returns it to the caller of the Create 
RPC, which returns it to the proxy. Once the distributed 
object proxy receives the reference, the proxy calls a Rebind 
(step 5) on itself using the reference. At this point, the proxy 
is setup with a one-to-one correspondence with a back-end 
interface object. 

If the user calls, e.g., selattr( ) on the proxy (step 6), the 
framework routes the call through a corresponding RPC. 
With regard to transactional work, any work that it is 
peformed by the distributed object that needs access to the 
database is accomplished via transactional RPCs between 
the proxy object and the back-end implementation (e.g., 
CURDL methods). The distributed objects perform CURDL 
methods using key values/attributes that are set (step 7) on 
the business objects. Typically, the client starts a transaction 
by invoking a transactional method, such as createObj( ) 
(step 8) on the proxy. This results in a transactional RPC to 
the back-end implementation (step 9). With the transactional 
RPC, a XA connection through Persistence is opened and the 
Persistence DAOs are constructed (step 10). All of the 
attributes are next copied from the back-end implementation 
to the DAO (step 11). The DAO is deleted (step 12), which 
flushes its data to the database 120. The XA connection is 
then closed. Thus, the Persistence DAOs never exists across 
a transaction RPC, as they are mainly used to pass data to the 
database. Once a client commits, all changes are committed 
to the database. Top level scenarios of the above are con- 
tained in Appendix A. 

The Data Access Object Manager Servers 150a-150p 
illustrated in FIG. 4 will now be described. The Manager 
Servers lS0a~lS0p are primarily used by the Dispatcher 
Brain 146£> of the Activity Management Subsystem 146. The 
services/methods provided by the Manager Servers 
150a-150/? are typically tasks of an Activity Plan. This 
section will highlight the medium grained services provided 
by the various Manager Servers 150a-150/? shown in FIG. 
4. As will be evident to those of skill in the art, the services 
are named are merely exemplary as other services may be 
performed by the various servers. 

The Meter Manager Server 150a is responsible for pro- 
viding all services related to meters 60. The Meter Manager 
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150a may provide services to add a meter, add a meter 
mapping, install or uninstall a meter, update meter data, 
terminate a meter, computer or verify a meter stage, set a 
meter connect status, and retrieve accounts or rates for a 
meter. 

The Rate Manager Server 1506 is responsible for provid- 
ing all services related to rates. For example, the Rate 
Manager 1506 may provide services to add or remove a rate, 
retrieve rate components, and assign and de-assign a meter 
to a rate. 

The Meier Group Manager Server 150c is responsible for 
providing all services related to meter groups (e.g. Accounts, 
Data Collection, etc.). To provide these services, the Meter 
Group Manager 150c will interact with the Account Imple- 
mentation Server, and the Data Collection Implementation 
Server. The Meter Group Manager 150c may provide ser- 
vices to add, modify or remove an account, retrieve meter 
rate for an account, terminate meter groups, retrieve meters 
for a group, assign meters to a group, de- assign meters from 
a group and compute a group stage. 

The Receiving Manager I50d is responsible for loading 
the received and mapped data into the repository. This is 
accomplished either through a bulk loading process for large 
shipments of data, or through the DAOs for individual 
on-request meter reads. The Receiving Manager 150a* may 
provide services such as receiving a meter reading, and 
receiving a but loading. 

The Reading Manager 150/r is responsible for retrieving 
reading samples from the AMR Data Repository 120. The 
Reading Manager 150fc services include retrieving readings 
(using freshness), assembling reading data, and retrieving 
readings for meter rates. 

The Capability Manager 150/ is responsible for determin- 
ing the abilities of a particular component instance. "Capa- 
bilities" are attributes of various types of component an 
AMR Server 15. For example, meters 60 of different types 
have different capabilities that can support. In addition, the 
different communication systems have different capabilities 
they support. "Abilities" are enabled "capabilities" for an 
individual component. In other words, abilities are instance- 
based. The Capability Manager 150; may provide services 
that assign capabilities and validate rate components. 

The Reference Data Manager 150n is responsible for 
efficiently providing various lists of reference data like 
meter ID's, meter types, communication types, etc. from the 
AMR Data Repository 120. The Reference Data manager 
150« utilizes Persistence DAOs directly to retrieve this 
information via simple queries from the AMR Data Reposi- 
tory 120. The Reference Data Manager 150n does not use 
proxy objects and hence an Implementation Server does not 
exist for reference data. This information is primarily uti- 
lized by the GUI Subsystem to obtain lists from the AMR 
Data Repository 120 for users to select from. The Reference 
Data Manager 150/1 a service to retrieve reference data. 

As discussed above with reference to FIG. 14, the Data 
Access Object Implementation Servers 150<z-150p contain 
the back-end implementation for the proxy objects and the 
Persistence DAOs. The back-end implementation provides 
users of proxies with services that operate on associated 
Persistence DAOs and, hence, their related Oracles tables. 
The services performed by the implementation servers 
below are provided for exemplary purposes and are not 
limited to only the noted services. 

The Meter Implementation Server 150a provides the users 
of meter proxies with the meter- related services, such as 
changing or setting a meter, and retrieving and setting meter 
configuration information. The Rate Implementation Server 
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150Z> provides the users of rale proxies with services, such 
as creating, updating and reading rate information from a 
meter. The Schedule Implementation Server 150/ provides 
the users of schedule proxies with services that include 
retrieving and schedule times and events. The Meter Group 
Implementation Server 150c provides the users of meter 
group proxies with services that include modifying meter 
groups, defining meter group properties, and mapping 
meters to groups. The Account Implementation Server 150/? 
provides the users of account proxies with services, such as 
determining account names, group status, and defining 
account information. The MeterGroupManager Server 150c 
is the primary server that will utilize the services of the 
Account Implementation server 150p through the proxies. 
The Data Collection Implementation Server ISOg provides 
the users of data collection group proxies with data collec- 
tion services. It is primarily the MeterGroupManager Server 
150c that will utilize these services through the proxies. The 
SampleDatalmplementation Server 150/ provides the users 
of sample data proxies with services, such as reading sample 
data, and determining validation information. The External 
Translation Implementation Server 150/i translates from 
external to internal representation and vice versa. All man- 
ager servers that require ID translations between internal and 
external representation utilize the services of the External 
Translation Implementation Server ISOh. Some typical 
objects that have external representations are: meters 60, 
rates, schedules, Communication Servers 30, accounts, data 
collection groups, etc. The External Translation Implemen- 
tation Server 150A provides the users of external translation 
proxies with services that perform operations on the asso- 
ciated Persistence DAOs and hence their related Oracles 
database tables. The External Translation Implementation 
Server does not have a specific manager server, but is used 
primarily by the Utility Interface 144. 

Referring again to FIG. 4, the AMR Server 15 is respon- 
sible for generating exports of data to the external applica- 
tion systems. The AMR Server 15 reports scheduled billing 
data, deferred requests, supplier performance statistics, etc. 
The data used for these reports is available through the 
business objects managed by the Business Object Servers. 
However the results are gathered, mapped, and formatted for 
the export to Application Systems. These services are encap- 
sulated by the Export Subsystem 152. The export operation 
is driven by activity plans specific to a export scenario, but 
the services necessary to produce the export are contained 
within the generator along with fine and medium-grained 
control objects. 

Referring to FIG. 4, the Export Subsystem 152 is com- 
prised of two servers, an Export Manager (EM) 1526 and a 
Validation, Editing, and Estimation (VEE) Manager 152a. 
These servers will process a large volume of data, so 
efficiency is an important consideration. One of the first 
functions the Export Subsystem 152 supports is generating 
a report for Billing. In order to perform the billing process, 
data may require validation, editing, and estimation. 

The data export subsystem 152 of the AMR Server 15 
uses template files to dynamically define what data is 
exported from the AMR database 120. The basic concept of 
the export process is to extract data for a given hierarchy of 
information from the AMR database 120for a given date 
range and write the data to a file using a specific file format. 
This file format is termed herein the AMR File Format. For 
example, an export of billing data from the AMR Server 15 
consists of producing a file containing a hierarchical group- 
ing of accounts, meters, data components and meter read- 
ings. That is, an account contains meters which contain data 
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components which contain meter readings, all of which are 
scoped by the supplied date range. A template file defines 
what attributes will appear in the export file for each object 
in the hierarchy. For example, a meter has many attributes 
associated with it, such as its transformer factor, meter id, 
communication status, type, etc., but for billing purposes, 
this information may not be relevant. However, for the 
purpose of loading this meter into another database, all of 
the attributes may be necessary. The concept of a template 
helps solve this problem by allowing specification of what 
attributes will be extracted from a given object for a par- 
ticular export job. Each type of export can use a different 
template, which allows extraction of only the required 
information. This advantageously provides for faster export 
times and smaller export files. 
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performance optimization to minimize the transport of data 
across the network and benefit from local Persistence object 
caching. FIGS. 34A-D illustrate the various threads execut- 
ing in the VEE 152a. 

The validation, editing and estimation tasks must be 
performed on raw data to certify the data as settlement 
quality. Associated with these validation checks are specific 
estimation algorithms that must be performed on the raw 
data when a validation checks fails. The raw and estimated 
data values may also need to be stored and maintained for 
years due to legal stipulations regarding billing disputes. The 
additional storage of estimated data not only compounds 
database sizing and performance problems, but also creates 
the need for temporal solutions (discussed below). 
A thorough analysis of abnormal billing scenarios yields 



The following is an example of a template entry for a 15 several situations that require an AMR Server 15 to maintain 



meter object in the AMR server 15. 
+Meter 

MeterId:meterid|getMeterId|long 
TransformerFactor:transf]getMeterMultiplier|rloat 
CommStatus:commst|get|CommunicationSlatus| 
RWCString 
-Meter 

As an example export, a script is used that maps the AMR 
Format File into the export format. As an example import, 
the import file may by converted into a set of C++ objects. 
The template is applied against the objects to produce the 
AMR Format File, similar to the business objects noted 
above. The AMR Format File is then loaded into the 
Receiving Subsystem 150a\ 



multiple versions of history of both the raw and estimated, 
data for a meter 60. For example, consider the scenario 
where all of the billing data from an individual meter cannot 
be collected due to a communication failure. The specified 
20 VEE rules will plug the missing data to produce settlement 
quality data for this meter to support the customer billing 
process. In the case where the actual raw data for this meter 
happens to arrive after the customer billing process has 
completed, then a bill adjustment process is required. The 
25 actual raw data received from this meter requires validation 
to be performed before it can be used to determine the 
appropriate bill adjustment. This validation process may fail 
any one of the specified validation tasks fail and require 
estimation to produce settlement quality data for the bill 



The Export Manager (EM) 152b is one of the agents in an 30 adjustment. For example, if in the future (one month later), 



activity plan. When generating a billing report, the EM 1526 
will receive a list of account IDs to process and a Utility ID 
and Role. For each account, the EM 1526 will retrieve a list 
of meters 60 for that account. The EM 1526 then interrogates 
each meter to determine the rate for the given Utility ID and 
Role. Once the Rate for that meter is known, the meter 
components can be determined. For each meter component, 
one or more readings are gathered. As is evident to one of 
skill in the art, this nesting of information wiU make it 



the customer has a billing dispute related to this abnormal 
billing period, a complete history of both the original and the 
adjusted billing transactions (including the raw and esti- 
mated data) will be required to resolve the customer dispute. 
35 Another example of billing abnormalities is a case where 
configuration data (e.g., the transformer factor) for a cus- 
tomer's meter was entered incorrectly and went undetected 
for several monthly billing cycles. In this case, the MDMA 
needs to correct the configuration data (transformer factor) 



difficult to assemble the export data in a mass query manner. 40 for the meter and recompute the several months of bills for 



Each reading is preferably validated (and possibly 
estimated) before it is exported. This creates a problem for 
EM 1526 in that data must be written for estimated readings 
and each reading must be updated as having been validated. 
In addition, this makes what would normally be non- 
transactional database operations transactional. Such opera- 
tions pose problems in that there is a limitation in the 
number of database operations that can be performed in a 
single transactional unit (smaller batch units), and that 
transactional reads involve XA overhead and can signifi- 
cantly slow the process. 

The Validation, Editing, Estimation (VEE) Manager 152a 
is responsible for performing the validation, editing, and 
estimation specified by a particular Regulatory Agency to 



this customer to determine the adjustment. Since both the 
original and recomputed raw and estimated data sets were 
used to support the billing process, this data must be 
maintained by the system to resolve any future billing 
45 disputes. 

In order to accomplish validation, editing, and estimation 
the VEE Manager 152a will use local Activity Plans and a 
local dispatcher to run these plans. This Local Dispatching 
approach has been designed for use in VEE 152a to take 
50 advantage of the fact that all primary objects used in VEE 
152a are in the same process space. The Local Dispatcher 
performs a Local Activity Plan which only executes Local 
Operations that carry out actions on local objects. Local 
operations generate a workflow slot, and a 



produce settlement quality data for export from the AMR 55 ForcedRereadNeeded, which indicates the need to reread the 



Server 15. As with all Encina® Servers in the system, the 
VEE Manager 152a uses the AppServer classes to receive 
service requests through RQS. The VEE Manager 152a uses 
a directed graph and the performer to execute different 
functions. Each request is for VEE 152a on a particular 
meter/rate combination and will be executed within its own 
thread. Although shown logicajly as existing within the 
Export Subsystem 152, the VEE Manager 152a is actually 
contained within the same process space as the Reading 
Manager. The VEE Manager 152a will nonetheless provide 
a separate interface and be bound to as if it was a separate 
server. It physically resides with the Reading Manager as a 



60 



65 



physical meter 60 or communication server 30 to retrieve 
more accurate readings for a specified time period and then 
reapply the readings to the VEE 152a. All parameters are in 
the blackboard. Other batched services may use the Local 
Dispatching approach for performance enhancement, if they 
also depend strictly on Local objects performing synchro- 
nously. This implementation uses a modified version of the 
infrastructure developed for the Activity Management Sub- 
system 146. The directed graph logic will contain the 
Regulatory Agency specific tasks and rules. 

The Local activity plan (workflow) acts as a task list 
which the Local dispatcher reads. For each task, the Local 
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dispatcher requests the Performer to perform the task. The 
Performer uses a method dictionary to lookup the Functor 
associated with the task. A Functor object executes the 
appropriate C++ method to do the actual work of the task. 

The VEE interface 152a is used by the other Subsystems 
within the AMR Server 15. The service provided by the VEE 
152a include checking for missing components, usage inter- 
val information, computing various consumption data, esti- 
mating load profile usage, determining if a meter requires 
maintenance, prorating usage and load profile, and estimat- 
ing usage. 

Referring now to FIG. 4, the Database (AMR Data 
Repository 120) is an Oracle® Relational Database Man- 
agement System (RDBMS.) The structure of the database is 
designed to represent a high-level object model, as shown in 
FIG. 16. 

With respect to data storage, two signal factors of the 
AMR Server 15 preferably utilizes a distributed approach 
because of the tremendous volume of data stored, and the 
extremely high rate of data capture, manipulation, and 



hosts operate separately under the control of a managing 
process, and the second being parallelization, in which a 
machine may have multiple CPUs, I/O busses, etc, and may 
further participate in a loosely-coupled cluster of machines 
s that address a shared disk farm. 

Meters 60 can be associated with one-or-more Rates, 
combined into Meter Groups, and have many Capabilities 
and Abilities. Capabilities are based upon meters types and 
specify the functionality supported by this meter type. 
10 Abilities are associated with a particular instance of a meter 
and represent capabilities that are enabled by the program- 
ming of this particular meter. Rates specify what data is 
required to be collected for particular purpose (i.e. Billing). 
When a Meter 60 is assigned to a particular Rate, the Meters 
15 Abilities are checked to verify that the Meter 60 can support 
the data requirements specified by the Rate. A Rate is made 
up of Data Collection Components. These components have 
various types (Load Profile Components, Consumption 
Components, etc.). These components have Readings 



extraction. For example, one meter undergoing 15 minute ™ (Consumption Reading, Load^ Profile Reading) that are 
load profile readings on 2 channels for 24 hours per day, 
having a 37 month data retention period, requiring an 
average of 63 bytes per row, one VEE reading per raw 
reading and a 10% re-read and re-validation, will require 
14.97 megabytes (Mb) of storage space for its readings only. 
Given this per meter storage requirement, data storage 
requirements are as follows: 
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associated with Data Samples. Meter Groups are associated 
with Schedules and are specialized into two types Account 
and Data Collection. 

Accounts are specialized groups that are related to the 
25 billing process. Accounts contain meters that have different 
Rates that are used to bill a particular customer. Data 
Collection groups are meters 60 that share the same Data 
Collection Components. These groups are primarily used for 
collecting like data from meters 60 possibly for export from 
30 the AMR Server 15 to an Application System. 

Each of the objects in the high-level object diagram of 
FIG. 16, is mapped to the database as illustrated in FIGS. 
17-25. 

FIG. 17 illustrates the logical architecture of the account 
35 management subsystem 150p. The account management 
subsystem 150p provides for operations on groups of meters 
60, and resolving many-to-many relationships between a 
group and its elements. FIGS. 18A-D illustrate the logical 
architecture of the capability manager 150;. As noted above, 



In addition, the data insert rate is also large. Using Ardis, 
communication with meters is available only 4 to 6 hours per 

day, usually between 10 p.m. and 4 am. In the 1000 meter 40 abilities are enabled capabilities. The capabilities are actions 



system scenario above this means the AMR database 120 
performs 96 raw readings per meter, with an average size of 
63 bytes per reading, or 96,000 inserts. This works out to 
4.44 inserts per meter per second for a six hour collection 
period. When scaling is considered: 
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a mechanism is capable of performing (e.g., measurement, 
information and control). Abilities may be enabled either 
intrinsically or explicitly. An ability belongs to a particular 
object and no others (i.e., abilities are instance -based). FIG. 
45 19 illustrates the logical architecture of the meter manager 
50a. As illustrated, the meter manager 150a provides for 
setting the communication parameters specific to a particular 
meter. The meter manager 150a also contains a list of the 
communication statuses that a meter may have, the status of 
50 a meter's electrical connection, the meter's current stage in 
the life cycle (e.g., ordered, inventoried, installed, readable, 
billable, terminated). FIG. 20 illustrates the logical archi- 
tecture of the rate manager 150b. The rate manager 1506 sets 
rates for particular meters 60 (or vice -versa). The data 
55 component (DC) instance is the application of a data col- 
lection template (DCTemplate) to a particular meter. Only 
certain combinations of DCTemplates are allowed. FIG. 21 
illustrates the logical architecture of the reading manage- 
ment server 150k. The reading management server 150k 



A conventional Unix relational database server installa- 
tion consists of a single Unix host with a single relational 
database server process (or set of processes). Given this 
configuration, conventional relational databases begin to 
experience trouble keeping up with an insert rate somewhere 
between 200 to 500 inserts per second. Thus, the conven- 60 provides for scalar readings (consumption or demand) or 

tional relational database server is inadequate to support the arrays (load profile or time of use) and the meter reading is 

desired scalability of the AMR database. To resolve this, the split between two tables (MeterSample and SampleData). 

data repository 120 of the present invention employs a The method of acquisition of each data point in a meter 

distribution of the workload. This is accomplished by using reading is determined for quality of data purposes, in addi- 
multiple hosts to perform database duties. This type of 65 tion to why the meter was read. FIGS. 22A-B illustrate the 

parallelization may take two forms. The first being a true logical architecture of the schedule manager 1386. The 

database distribution, in which multiple, wholly separate schedule manager 1386 provides for setting the periodic 
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delivery schedule of exported data to a utility. To perform 
the exportation, the external characteristics of the data are 
set, e.g., file name, when to deliver the data. The schedule 
manager 1386 is also responsible for scheduling of all 
workflows. The expected time for each workflow and a total 
number of workflows are taken into account to determine 
when to start the workflow so that the system is not 
overloaded. Receiving events and internal events within the 
AMR are also scheduled by the schedule manager 138b. For 



(row) in a relation (table). It accomplishes this by using the 
timestamp datatype to append two time periods to each 
tuple: Valid time and Transaction time. 

Valid and Transaction each have two boundaries, start- 
Time and endTime. The two periods are orthogonal, i.e., 
they record different, independent aspects of the tuple. The 
Valid period is the time range during which a fact is true. The 
Transaction period is the time range during which knowl- 
edge of a fact is current, or stated another way, the time 



example, data to be received from a supplier is scheduled as 10 range during which a fact is recorded in the database. The 

well as actions the AMR may have to take to make the data temporal timestamp is modeled as two dependent relational 

available to the utility. attributes, startTime and endTime, where startTime is 

The logical view of the Schedule Manager 150/is shown always be less than or equal to endTime. 

in FIGS. 23A-E. The ScheduleManagement subsystem The boundaries of the two time periods also have different 

accepts requests via workflow create and update schedules 15 meanings. For Valid, the startTime is when a fact becomes 



of data collection. It is the Encina® server interface for 
building workplans (Activity Plans) for billing schedules. 
ScheduleBuilder builds workplans by arranging the activi- 
ties in the various schedules into jobs, determines when to 
start the activities, and to set the alarms to trigger execution. 20 
For example, when a new billing schedule is entered into the 
system, a delivery schedule for the supplier of the data needs 
to be determined. In addition, a workplan for a range of time 
needs to be built including, finding all schedules with times 
within the range, arranging in chronological order, figuring 25 
start times that result in acceptable finish times, putting jobs 
into a workplan, setting alarms to trigger the jobs and RPC 
operation for the subsystem. In addition, actions scheduled, 
event conflicts, and whether an event subsumes another 
event are also determined. A schedule task is something to 30 
do at a schedule time. As noted above, it consists of "what 
to do" and "when to do it" <f What to do" is a scheduleEvent, 
which carries all of the information about the activity. 
"When to do it" is a scheduleTime, which carries all of the 
timing information. 35 

FIG. 24 illustrates the logical architecture of the System- 
Parameters. The System Parameters are a catalog of the 
properties of the AMR Server 15. They can be used to set 
defaults on a system-wide basis, and set utility defaults on 
a utility-wide basis. FIG. 25 illustrates the logical architec- 40 
ture of the TranslationService 150A. The TraaslationService 
ISOh may be used to validate fields such as state and zip 
codes, and determining a regulatory agency for a jurisdiction 
in which the meter resides. 

Relational databases suffer from a deficiency in that they 45 
generally hold only current data, as all previous versions of 
the data are overwritten. Thus, the relational database 
approach will not provide an historical view of the data. The 
solution to this problem is to use a temporal framework 
approach. This approach includes augmenting the database 50 
to hold two timestamp ranges for each table, enhancing the 
stored procedures to perform the temporal equivalent of 
relational inserts, updates and deletes, providing a templated 
technique for selecting the correct version of data from the 
database for different views of history, and performing 55 
relatively minor recoding of application servers to use the 
temporal framework. 

The database 120 is implemented utilizing temporal 
timestamps on the relational tables. An explanation of the 
use of temporal timestamps on relational tables follows. The 60 
Bitemporal Conceptual Data Model is preferably used in the 

AMR Server 15 because of the capability of this model to Meterld is the primary key of tin* "Meter table, while Meter- 
meet the requirements of the electrical deregulation infor- Type is an a periodic time-variant attribute. OCA is the 
mation marketplace. Optimistic Control Attribute; it is compared to the OCA 

The Bitemporal Conceptual Data Model is an extension of 65 value stored in a passivated proxy object, to determine if the 
the relational data model which allows for two independent, data retrieved from the database represents the state of the 
orthogonal time periods to be associated with each tuple proxy object before passivation. Vs and Ve are the start time 



true or effective. The Valid endTime is when a fact ceases to 
be true. For the Transaction time period, startTime is when 
a fact (row) was recorded in the database; endTime records 
how long the fact represents the current state of the relation. 
In other words, the endTime records the expiration or 
deletion time of a fact as representing current relations. 

With regard to database operations, there are three pos- 
sible write operations that involve temporal timestamps: 
inserts, updates, and deletes. In addition, there are two 
possible scenarios for updates: the Valid attributes are modi- 
fied or not modified. Modification of Valid timestamp may 
be done to reflect a new understanding of the lime period 
during which a fact was (is) true. In the temporal sense, the 
three database write operations work as follows: 

1. During an insert, a row is inserted into the appropriate 
database table. 

2. During an update, a new row with the updated data is 
inserted into the appropriate daiabase table. The Trans- 
action endTime of previously current row is updated to 
the commit time of the update operation. 

3. During a delete, the current row is not truly removed 
from the database, but is logically deleted by updating 
the Transaction endTime to sometime less than infinity, 
though not necessarily less than or equal to the delete 
operation commit timestamp. If the Transaction end- 
Time is set to a time greater than now, the fact is current 
until that time, i.e. the fact is preset to expire at the 
Transaction endTime. 

As an example, one meter may have many rales and one 
rate may apply to many meters 60. What needs to be 
determined is when this relationship of meters 60 and rates 
is effective (valid). That is indicated by the Valid and 
Transaction timestamps of the Meter, Rate and the intersec- 
tion table that resolves the many-to-many Meter-Rate rela- 
tionship. Some samples of those tables are shown below: 

TABLE 1 









Meter 
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Melerld 


Type 


OCA 


Vs Ve 


Ts 


Te 


1 


AID 


0 


4-1-1998 2-5*2037 


4-1-1998 


2-5-2037 


2 


A1K 


0 


4-1-1998 2-5-2037 


4-1-1998 


7-4-1998 


2 


A1-K2 


1 


4-1-1998 2- c -2037 


7-4-1998 


2-5-2037 
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and end time boundaries of the Valid timestamp. Ts and Te 
are similar. It is helpful to think of these two values as 
comprising one datatype. As shown in Table 1, Meter 1 has 
meter type AID, and this is valid and current from April 1st 
forward. This is an example of a straight insert. Meter 2 
originally had meter type A1K, and this was valid from April 
1st forward, and current from April 1st until July 4th. The 
meter type for meter 2 was changed to A1-K2 on July 4th, 
and became the current fact. Note, since the valid timestamp 
was not changed, this reflects a correction of the meter type 
back to April 1st, in essence correcting the history of the 
meter. This is an example of an update that does not modify 
the Valid timestamp. Note the OCA value for Meter 2 also 
changed from 0 to 1. This flags the row as being different 
than before, and is used for optimistic locking. Optimistic 
locking will be discussed below. 



TABLE 2 









Rate 






Rate 








Ts 


Te 


Id 


RateTypc 


OCA 


Vs Vc 






10 


LP KVA 


0 


4-1-1998 4-25-1998 


4-1-1998 


4-15-1998 


10 


LP KVAR 


1 


4-26-1998 2-5-2037 


4-15-1998 


2-5-2037 


11 


CONS 


0 


4-1-1998 2-5-2037 


4-1-1998 


2-5-2037 



As shown in FIG. 2, Rate 10 has rate type LP KVA as the 
current rate type from April 1st until April 15th, at which 
lime the customer requests to change the rate type to LP 
KVAR at the end of the fourth billing cycle. The valid period 
for the previous rate type ends at the end of the 4lh billing 
cycle (April 25th), and the new rate type is valid from the 
beginning of the fifth billing cycle (April 26th) forward. The 
change was recorded in the database on April 15th, however, 
and so becomes current at this time. This logical update 
represents a new state for Rate 10. This is an example of an 
update that does modify the Valid timestamp. Rate 11. is 
another example of a straight insert. 



TABLE 3 







MeterRate 






Meterld 


Rateld 


OCA Vs 


Ve 


Ts 


Te 
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11 


0 4-1-1998 


2-5-2037 


4-1-1998 


2-5-2037 


2 


10 


0 4-1-1998 


4-25-1998 


4-1-1998 


4-15-1998 
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10 


1 4-26-1998 


2-5-2037 
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As shown in Table 3, MelerRate is an intersection table 
that resolves the many-to-many relationship between Meter 
and Rate. As such it has a two part key, Meterld and Rateld. 
For MeterRate (1, 11), the association between Meter 1 and 
Rate 11 becomes valid on April 1st and continues forever. As 
used herein, the term "forever" refers to the date 2-5-2037, 
as this is the latest date that may be represented by the 
preferred database software. The association between Meter 
1 and Rate 11 is also current for the same time period. It 
represents a straight insert into the intersection table. 

For MeterRate (2, 10), there are two possibilities. The first 
possibility is represented above in Table 3. When Rate 10 
changed on April 15th, Meterlfete could be updated to 
reflect a change in the association, i.e. MeterRate (2, 10) 
shows the state change of one of its associates. Another 
possibility is that the association itself has not changed, so 
the two rows shown above for MelerRate (2, 10) could be 
represented by a single row: 
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TABLE 4 
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2-5-2037 
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0 4-1- 
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10 With this representation, however, the ability to distinguish 
which rate to use during the association's Valid time period 
is ambiguous. If selecting the current state, Rate 10 with the 
current Transaction timestamp (the one whose endTime is 
greater than now) would be used. During a billing run for 

]5 billing cycle 4, Rate 10 with the Valid timestamp(s) that span 
the billing cycle time period is used. The logic used to select 
the correct Rate 10 representation can be inherent to the 
navigation of the relationships in Table 3. If represented as 
in Table 4, it is left to the programmer to sort out which Rate 

20 10 representation to use. Techniques for selecting the correct 
data are presented below. 

Changes to Valid times may cause an overlap with the 
Valid time period of other versions (rows) of the entity 
instance. In this case, a special operation, coalescing, may be 

25 required. It is noted that this should not to be confused with 
the Oracle® COALESCE operation. Two or more rows with 
identical non-temporal attribute values are value -equivalent. 
Value-equivalent rows with adjacent or overlapping time 
periods represent a temporal extension of a single fact and 

30 therefore should be coalesced into a single row. This is the 
case with MeterRate (2, 10) present in Table 3, if the OCA 
value is not taken into account. The coalescing operation is 
similar to duplicate elimination in a "select distinct" opera- 
tion. 

35 Coalescing is an extremely expensive operation in a 
purely relational database engine, and should be avoided if 
possible. To determine how to avoid coalescing, it is nec- 
essary to examine the three ways in which value-equivalent 
rows may materialize in a database. 

4 0 The first way value-equivalent rows may appear is 
through the insert of value-equivalent rows with differing 
timestamps. Consider Table 5: 



TABLE 5 
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In Table 5, the validity of MeterRate (2,10) is extended from 
April 25th to forever, and the currency is extended from 
April 15th until forever. These two rows are value- 
55 equivalent and have adjacent timestamps. Therefore they 
may be coalesced into a single row without any loss of 
semantic information, as shown in Table 6. 



TABLE 6 
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The coalescing operation, however, is performed either in 
the application modifying the data, or by the database stored 
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procedure code. If performed by the C++ programmer, the 
appropriate coalescing pre-conditions are detected and a 
method called that literally updates the database, rather than 
performing a temporal update. If performed by the insert 
stored procedure programmer, each new record inserted into 
the database are preferably tested with all other records of 
the same primary key. If coalescing criteria are met, the 
stored procedure extends the Valid or Transaction 
tiraestamp, or both, of an existing row by performing a 
classic database update. 

To effectively perform coalescing in C++ code, the pro- 
grammer needs to perform a search for value -equivalent 
rows prior to every insert, retrieve any candidates, evaluate 
the coalescing criteria, and call a special method that per- 
forms a classic database update on an existing row. This 
algorithm is also duplicated for each low level proxy imple- 
mentation. This technique, however, is expensive in terms of 
processing time and network bandwidth, but has the advan- 
tage in a multi-tiered environment of spreading the work 
over many processes. It may also be templated, after a 
fashion, and the requisite code generated by the Proxy code 
generators. 

Code generators are like software production lines, given 
an order, the generator creates reproducible code that shares 
characteristics with other units from the production line. To 
further the analogy, an automobile manufacture's models 
differ from each other in size, model, style, color, options, 
and price. Each automobile, however, shares a core set of 
similarities that enable the driver to operate any of the 
vehicles without retraining. For instance, steering wheels 
always are round, and when rotated clockwise cause the 
vehicle to turn right. The pedal layout and operation is 
always the same. Gauges present familiar information, 
though possible in a different format. Fuel is standardized, as 
is the basic drive train operation. This standardization 
extends to the production line that produced the automo- 
biles. Though the list of available options is fixed for a 
certain model and year, each customer can specify which 
options they want for their vehicle. The production line can 
then take this specification and produce the appropriate 
vehicle for that customer. The customer is then responsible 
for any further customization they wish to make to their car. 

The code generators serve a similar function in the AMR 
Server 15. By creating the specification for an AppServer, 
Proxy, or DAO, the programmer can have most of the 
standard, shared code generated for them. This code repre- 
sents a substantial portion of the code required to implement 
one of these classes. Furthermore, the result is reproducible, 
since the code is not hand-built each time, which reduces the 
potential for error and rework time. Thus, the overall quality 
of the AMR Server 15 is thus vastly improved by using code 
generators, and the cost in terms of time is proportionalely 
reduced. 

If the insert stored procedure is responsible for coalescing, 
it also evaluates the table for any value-equivalent rows with 
satisfy the coalescing criteria, and then perform a classic 
database update on an existing row. This approach has the 
disadvantage of localizing all processing in the database 
engine, which is less distributable than Encina® servers. 
Localization can become an advantage, however, in (hat it 
simplifies the C++ programmers' job, and the stored proce- 
dure code can be generated via an appropriately modified 
generator. Also, this approach trims network traffic, which 
preferably avoids bottlenecks in overall AMR Server 15 
throughput. 
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The second way value -equivalent rows may appear is by 
temporally updating a row with adjacent or overlapping 
timeslamps. Table 7 shows the Meter table containing a 
single row, valid and current forever. 



TABLE 7 
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0 4-1-1998 2-5-2037 
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2-5-2037 



If that row is temporally updated (a new row is inserted and 
is made current, and the Te value of the existing row is 
changed to the commit timestamp) with value-equivalent 
values, a new row results, as shown in Table 8. 

TABLE 8 
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This condition may be most easily avoided by detecting the 
value -equivalence of the "new" row in the proxy code, and 
3Q disallowing the update. 

A third way value-equivalent rows may appear is by 
updating a row to become temporally adjacent or coincident 
with another row, as shown in Table 9. 

35 TABLE 9 
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Suppose Meter 2 was assigned to Rate 11 by mistake. If 
MeterRate (2,11) is corrected to reflect that the rate should 
really have been Rale 10 instead of Rate 11, the result is 
shown in Table 10. 



TABLE 10 
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If this operation is allowed, then the three rows above 
60 represent a single, temporally continuous fact about Meter- 
Rate (2, 10) and should be coalesced. There is a problem 
with this specific operation. As a matter of policy, are 
"mistakes" valid data, and therefore are kept in the history, 
or may they be corrected without loss of information? If the 
65 former, then modifying the Rateld of MeterRate (2, 11) 
should be disallowed, and a temporal update applied instead. 
This results in Table 11. 
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TABLE 11 
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4-1-1998 


5-1-1998 


2 


11 1 4-25-1998 6-1-1998 


5-1-1998 


7-1-1998 


2 


10 2 6-1-1998 2-5-2037 


6-1-1998 
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10 3 4-25-1998 6-1-1998 


7-1-1998 


2-5-2037 



By examining the Valid timestamps, it is seen that rows 1, 
4, and 3 have adjacent and overlapping validities, and 
therefore form a temporally continuous single fact with 
respect to validity, i.e. row 2 represents a mistaken state. If 
they are coalesced, however, the details of the mistaken 
history shown in row 2 are obliterated. 

By examining the Transaction timestamps of rows 1, 4 
and 3, it is seen that rows 1 and 4 are not temporally 
adjacent, even thought their validities are temporally adja- 
cent. Furthermore, rows 3 and 4 have overlapping Transac- 
tion and Valid periods. These two rows may be coalesced 
without loss of information, since the Valid period for the 
mistaken fact lies wholly within the Valid period of the 
coalesced rows 3 and 4, and the Transaction period for row 
3 holly contains the Transaction period for row 4. The result 
is presented in Table 12. 



TABLE 12 







MctcrRatc 






Meterrd 


Rateld 


OCA Vs Ve 


Ts 


Te 


2 


10 


0 4-1-1998 4-25-1998 


4-1-1998 


5-1-1998 


2 


11 


1 4-25-1998 6-1-1998 


5-1-1998 


7-1-1998 


2 


10 


2 4-25-1998 2-5-2037 


6-1-1998 


2-5-2037 



Note the Valid periods for rows 1 and 3 are adjacent, and the 
Transaction period for row 3 is later than the Transaction 
period for row 2, indicating row 3 supersedes row 2. The 
same information now occupies 37 fewer bytes. 

To further illustrate this example, suppose a billing run 
was made in May on the above data. Row three would not 
have existed yet, so the mistake Rate 11 would be used in the 
billing run. Once the mistake was discovered in June and 
corrected, another billing run would use Rate 10 to publish 
the amendment to the May results, and Rate 10 would be 
used thereafter. Furthermore, the fact that an incorrect rate 
had been used at one time could be detected and accounted 
for, without degrading the proper performance of the system. 

If Table 11 is reordered somewhat, the result is Table 13. 
Note the order of rows 4 and 3 are swapped. 



TABLE 12 







MeterRate 






Meterld 


Rateld 


OCA Vs Ve 


Ts 


Te 


2 


10 


0 4-1-1998 4-25-1998 


4-1-1998 


5-1-3998 


2 


11 


1 4-25-1998 6-1-1998 


5-1-1998 


7-1-3998 


2 


10 


3 4-25-1998 6-1-1998 


7-1-1998 


2-5-2037 


2 


10 


2 6-3-1998 2-5-2037 


6-1-1998 


2-5-2037 



The second and third rows show the "mistaken" fact and the 
"corrected" fact. This reordering makes it apparent that 
MeterRate (2, 10) has been the valid association since April 
1st. This is shown by the continuity is indicated by the 
adjacent Valid timestamps and the temporally greater (later 
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in time) Transaction timestamp of row 3 compared to row 2. 
When asking the question "How long has Meter 2 been on 
Rate 10?" the time range that answers that question begins 
on April 1st and continues to now. This implies that the 
5 query should return a single answer, rather than multiple 
consecutive, adjacent results. This type of coalescing is done 
at query time, rather than during a database write. 

Each scenario presented above should be examined and 
benchmarked to determine the most effective and efficient 
techniques for implementing history in the production AMR 
Server 15. 

With regard to data manipulation techniques, the follow- 
ing clauses are used. To select the current version of the data, 
the following where clause is used in the select statement: 

where transactionTimeStart<:now 

15 

and transactionTimeEnd>:now 
where :now is a variable holding the select transaction start 
lime. 

To select a version of data that matches a specific date, use 
2Q the following where clause: 

where :specificDate between validTimeStart and valid- 
HmeEnd 

where :specificDate is the specific date of interest. 
To select a version of data that falls in a certain time period, 
25 use the following where clause: 
where validStartTime 

between :timePeriodStart and :limePeriodEnd 
and validEndTime 

between :timePeriodStart and :timePeriodEnd 

30 The latter where clause is typical of navigational queries that 
traverse the relational schema, weaving the relationships 
between parent and dependent tables. The two variables are 
the boundaries of either the Valid or Transaction period of 
the parent record. The following explains the transitions 

35 each period experiences during database write operations. 
All times are recording in the UTC time zone. 

During an insert, a row is inserted into the appropriate 
database table. The policy for the Valid and Transaction 
periods is as follows: Valid startTime may be set to a past or 

40 future date. If not set, if will default to the commit time of 
the database transaction. Valid endTime may be set to a past 
or future date, so long as it is greater than the Valid 
startTime. If endTime is not set, it defaults to infinity, which 
occurs on February 5, 2037 (the maximum time Rogue Wave 

45 can accommodate, RWTime(UINT_MAX) ). Transaction 
startTime is set to the commit time of the database transac- 
tion. This is kept consistent between all database writes that 
occur during a single database transaction. Transaction 
endTime is set to RWTime(UINT_MAX). 

50 During an update, a new row with the updated data is 
inserted into the appropriate database table. The Transaction 
endTime of previously current row is updated to the commit 
time of the update operation. The policy for the Valid and 
Transaction periods of the new row is as follows: Valid 

55 startTime may be updated. If it is, Valid startTime may be 
changed to a past or future date. It may not exceed the 
endTime. If startTime is not updated, it will not be changed 
in the database. Valid endTime may be updated. Valid 
endTime may be changed to a past or future date, so long as 

60 it is greater than the Valid startTime. If the endTime is not 
updated, it will not be changed in the database. Transaction 
startTime is set to the commit time of the database transac- 
tion. This is kept consistent between all database writes that 
occur during a single database transaction. Transaction 

65 endTime is set to RWTime(UINT_MAX). 

During a delete, the current row is not truly removed from 
the database, but is logically deleted by updating the Trans- 
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action endTirae to some time less than infinity, though not 
necessarily less than or equal to the delete operation commit 
timestamp. If the Transaction endTime is set to a time 
greater than now, the fact is current until that time, i.e. the 
fact is preset to expire at the Transaction endTime. This can 
become problematic, however, and is not recommended. 
Valid startTime is not changed. Valid endTime is not 
changed. Transaction startTime is not changed. Transaction 
endTime is updated to the commit time of the delete 
operation. 

The functionality of Bitemporal Conceptual Data Model 
accommodates both strategic and tactical directions of data- 
base vendors, standards, and the AMR Server 15, and it is 
preferably utilized to meet the needs of a deregulated 
electric utility industry. 

As shown in FIGS. 3 and 4, the AMR Server 15 supports 
many External Application Program Interfaces (APIs) 124 
and 132. The AMR Server 15 provides a DCE Remote 
Procedure Call (RPC) API for application systems. External 
systems will require DCE in order to utilize the AMR Server 
15 API. DCE is supported on all major platforms including 
mainframes, UNIX sewers/ workstations, and PCS. The 
AMR Server 15 API provides an external system with access 
to services within the AMR Server 15. 

The initiator of an RPC call acts as an RPC Client and the 
recipient of an RPC call acts as an RPC Server. Each API 
service request returns the status of the request. Note that all 
API calls return the DCE error status. The diagrams below 
show the high-level interactions of the service initiator and 
recipient. 

The following will highlight the API calls available to an 
RPC Client running in an Application System (APIs invoked 
from Application System to AMR). 



Meter life Cycle APIs: 



Add Meter 
Synchronous Request 



Install Meter 

Synchronous 

Request 

Uninstall Meter 

Synchronous 

Request 

Modify Meter 

Synchronous 

Request 

Terminate Meter 

Synchronous 

Request 



Defines a metei in the AMR database. 
The addition/definition of a meter to the 
AMR database is done by the Primary 
Metering Utility (or third -party vendor). 
Records the physical installation of a meter 
at its location. 

Records the physical removal of a meter 
from its location. 

Modifies the definition of an existing 
meter. 

Removes the meter from the database after 
a specified expiration. 
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-continued 


Account Life Cycle APIs; 


Modify Account 


Modifies the definition of an existing 


Synchronous 


account. 


Request 




Terminate Account 


Terminates an account. The account 


Synchronous 


must not have any meters 60 assigned to 


Request 


it. 



Rates include the functions necessary to define and man- 
age rates including usage and interval data. Different meters 
60 for the same account may be on different rates; however, 
a single meter may only be associated with one rate at a time. 
Data available in the meter that could be used as "billing 
data" (and therefore included in the billing data required by 
a rate type) includes total "*" for this billing period, and 
load profile (typically 5, 15, 30, or 60 minute); where "*** 
may be any of the following: kW(h) delivered, kW(h) 
received, kVA(h) delivered, kVA(h) received, kVAR(h) 
delivered, kVAR(h) received, kVAR(h) for quadrants 1, 
2,3,4, kQ(h) delivered, kQ(h) received, and Power factor for 
peak demand, time-of-use peak demand and load profile. 



30 



35 



Create Rale 

Synchronous 

Request 



Assign Rate to 
Meter Synchronous 
Request 

Remove Rate from 
Meter 

Synchronous 
Request 
Delete Rate 
Synchronous 
Request 



Rate APIs include: 

Defines a Rate in the AMR database. A 
rate consists of one or more Data 
Components that provide specific 
information required for calculating a 
bill. 

Assigns a rate to a meter. 



Removes a rate from a meter. 



Deletes a rate from the AMR database. 



With regard to interval data, the data is normalized when 
the clock in the meter does not agree with the clock in the 
computer reading the meter. This phenomena is called 
"clock drift/' Clock drift can be either positive or negative 
depending upon whether the real time (at the computer) is 
greater than (negative drift) or less than (positive drift) the 
clock in the meter. 

Metering data includes the functions necessary to retrieve 
meter-reading information used for billing and for informa- 
tion (rate studies), and sends it to the appropriate system(s). 
This includes both consumption and interval data. 



Account Life Cycle APIs: 



Add Account 

Synchronous 

Request 

Add Meter to 

Account 

Synchronous 

Request 

Remove Meter from 
Account 
Synchronous 
Request 



Adds a new inactive account. An 
account may refer to a new or existing 
service. 

Adds a meter to an account. The account 
may or may not have other meters 60 
associated with it. 

Disassociates a meter from an account. 
This.disassociation does not physically 
remove the meter. 



On Request Meter 
Read 

Asynchronous 
Request 



Export Scheduled 
Billing Data 
Asynchronous 
Notification 



Retrieves meter readings on request for a 
specific meter from the database using 
specific retrieval parameters that arc 
passed with the request. If the readings 
stored in the database arc not recent 
enough, the reading is retrieved from the 
meter. This retrieval can be done via a 
meter, account, or data collection group. 
Collects billing data based on a schedule 
and prepares the billing data in a 
"Destination File." The customer is 
notified that the billing data file is ready 
for retrieval. Validation must be done to 
data prior to shipping 
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-continued 



-continued 



Export Metering 
Data Asynchronous 
Notification 



Enter Data Manually 

Synchronous 

Request 



Import Metering 
Data Synchronous 
Request 



Records how the scheduler, an operator, 
cr external system exports interval data 
from the AMR database to an external 
system. The export data can be in a 
range of times/dates and for a data 
collection group, specific meter 
channels, or meters 60. 
Records the manual entry of meter data 
into the AMR database when an AMR 
reading is unavailable. The read could 
be actual or estimated. The reading is 
rjQt imported from a file. 
Records the importing of Data 
Components for meters 60 from an 
external system or operator. This data 
may come from the meter via a device 
such as a hand-held and then entered into 
the system through this import process. 
The import of metering data represents a 
scenario that is not typical or automatic. 



Group APIs are as follows: 



Delete Data Removes a data collection group from 

Collection Group the AMR database. A group can only be 

Synchronous deleted when there are no meters 60 

Request associated with it. Data is still available 

for retrieval until data retention period 

expires. 



Administrative APIs: 



20 



Synchronize Meter 
Time 

Synchronous 
Request 

Validating Editing 
and Estimating Data 



Verifies the time inside a meter. 



The scheduler includes Billing Scheduling functions nec- 
essary to define which meters 60 are to be read on which 
days for billing or information purposes. The billing read 
schedule includes the "billing day", and identifies other 
information necessary to collect and process billing data. An 
account is assigned a rate and assigned to a billing schedule. 
The associated APIs are as follows: 



25 



Create Billing 
Schedule 

Synchronous Request 



Assign Account to 
Billing Schedule 
Synchronous 
Request 

Remove Account 

from Billing 

Schedule 

Synchronous 

Request 

Delete Billing 

Schedule 

Synchronous 

Request 



Defines a billing schedule for the AMR 
database according to the schedule given 
to it by a customer. The schedule specifies 
both when billing readings are delivered to 
the billing system and what actually 
constitutes a valid billing reading 
(freshness). 

Assigns an account to a specific billing 
schedule. 



Removes an account from a specific 
billing schedule. 



Deletes a billing schedule from the AMR 
database. 



Group APIs are as follows: 



Create Data 
Collection Group 
Synchronous 
Request 

Add Meter to Data 
Collection Group 
Synchronous 
Request 



Delete Meter from 
Data Collection 
Group Synchronous 
Request 



Defines a data collection group. The data 
collection group defines metering data 
components that arc to be periodically 
retrieved from the meter and stored in the 
database. 

Adds a meter to an existing data 
collection Group. The request includes 
the name of the data collection group 
and a list of meters 60 to be added to the 
group. A meter may belong to more 
than one data collection group. 
Removes a meter from a data collection 
group. The removal stops data 
collection for that meter. Previously 
collected data is still available for 
retrieval based on retrieval rules. 



The AMR Server 15 tracks the electrical service connec- 
tion status (Disconnect/Reconnect) of meters 60 within its 
database. For example, once a meter technician has physi- 
cally connected or disconnected electrical service to the 
premise, notification can be sent to the AMR Server 15 via 
the Modify Meter API and the appropriate meter status flag 
is updated. In addition, meter readings can be obtained and 
identified as "connect" or "disconnect" readings in the 
30 database with their associated date/time stamps and reason 
codes. 

Supplier System Interfaces (APIs) will now be described. 
The AMR Server 15 provides services allowing the auto- 
mated meter reading of different types of electrical mea- 
35 surements from a variety of meter types and communication 
networks. These services integrate the diverse types of 
meters 60 and communications servers into a uniform flow 
of data that will better support the business and engineering 
units of utilities. 
40 The services provided by the AMR Server 15 should be as 
transparent as possible to the type of communication 
network(s) used by the utility. The Supplier API is a set of 
common APIs that shield the particulars of vendor-specific 
Communication Servers 30 and networks from the utility 
45 and from the AMR Server 15 application software. If a 
utility desires to add another type of communication net- 
work into the AMR Server 15, this will only require the 
addition of a new communication interface in the AMR 
Server 15 and will not impact the utility or AMR application 
software. 

Supplier API presents different scenarios of the Commu- 
nication Server 30 API interacting with the AMR Server 15 
in both synchronous and asynchronous communication 
modes. The API is utilized as an interface between AMR and 
communication server. Some APIs will be called from the 
AMR Server 15 to Communication Servers 30, while others 
may be invoked from Communication Server 30 to the AMR 
Server 15. Not all APIs will apply to a particular commu- 
nication server. If an API is not applicable to a specific 
communication server, the API can still be called, but will 
return the status code AMR_NOT_SUPPORTED. In 
general, all APIs interact with the supplier interface in the 
AMR Server 15. However, the receiving Subsystem will 
process data received from bulk delivery and on-request 
reads. 

The AMR Server 15 faces the challenge to accept a 
variety of data types (i.e., formats) from different types of 
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meters 60 and Communication Servers 30. Therefore, a 
flexible data format is needed to facilitate data mapping and 
integration. At the same time, in order to make the API 
type-safe and prevent potential run time errors, the AMR 
Server 15 has fixed data types. The AMR 10 employs DCE's 
enumerated unions so that each different structure can be 
supported at run time, while still giving some type checking. 
Extensions to the API can be done without affecting older 
clients by using DCE version numbering. In some cases, a 
tag-value based data format can be used for maximum 
flexibility. Such a format applies tags to all the -values. The 
beauty of this format is its ability to store any type of data 
with tags defined; however, it could increase the size of the 
data for an API. The tagged fields will predominantly be 
used for parameters like UtilityContext that can have any 
information the utility or company wants AMR Server 15 to 
carry by way of context information. The top level scenarios 
of the Supplier APIs are contained in Appendix A. 

APIs Invoked From Communication Server 30 to AMR 
are as follows: 



APIs Invoked from AMR to Communication Server 30 
are as follows: 



DeleteMetcr 

OnReques tMet erRead ings 



AddDeltverySchedule 



AddCollectionComponents 



SynchMelerTime 



AddMeterCcmponentSchedulc 



GetMeterConfig 



DeleteCo! lection -Component 



Adds a new meter to 
communication server. 
Deletes the specified meter. 
Requests the meter reading 
data for the specified meter. 
The reading data may consist 
of consumption and/or interval 
data depending upon input 
argument Co mponen (Array. 
The data is returned in 
tileName. 

Creates a new schedule with 
the given schedule ID for data 
delivery from the 
Communication Server 30 to 
the AMR Server IS. 
Creates collection components 
for consumption and/or 
interval data on the 
Communication Server 30 and 
returns the assigned 
component IDs. 
Requests time synchronization 
for the specified meter. The 
DCE Distributed Time Service 
Local to the communications 
server is used as the time 
source. 

Assigns the specified 
collection components and 
delivery schedule to the 
specified meter. 
Retrieves meter configuration 
and type information for the 
specified meter from the 
communication server. 
Deletes collection components 
from the communication 
server. 
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-continued 



Delete Delivery- Schedule 



DcleteMeterComponentSchedulc 



Deletes a schedule for delivery 
from the communication 
server. 

Deletes delivery 
schedule/collection component 
assignments for the specified 
meter. 



DiscovtrMctcr 


Informs the AMR Server 15 that a new 




4. 




meter has been found in the field. 


25 




BulkDelivered 


Notifies the AMR Server 15 that 






consumption and/or load profile bulk 




5. 




data for the specified delivery schedule 






has been delivered and is available in the 








specified file. 




6. 



An AMR Server 15 Scenario for an on request meter 
reading will now be described with reference to FIG. 26. The 
following numbered steps correspond to the numbered flows 
illustrated in FIG. 26. 

1. The user presses "Submit" on AMR Java™ application. 

2. The ConfigUtility Encina® Server performs back-end 
support for the Java™ application and messages the 
OnRequestMeterRead Utility Interface API . 

3. UtilityMgr Encina® Server houses the Utility Interface 
APIs. For this call, UtilityMgr uses the Meter Proxy 
and Rate Proxy to populate the appropriate data and 
requests execution of the OnRequestMeterRead work- 
flow. 

. Dispatcher Panel Encina® Server retrieves the OnRe- 
questMeterRead workflow, assigns it a workflow id, 
and queues a message to DispalcherBrain. 
. DispalcherBrain Encinal Server executes the OnRe- 
questMeterRead workflow: 

. Brain queues a message to ReadingMgr Encina® 
Server requesting GetReadingsUsingFreshness service. 

7. ReadingMgr uses SampleData proxies (ReadingMgr 
Encina® Server) to read samples from the AMR data- 
base. 

8. If return status is STS_STALE_READINGS then 
35 DispalcherBrain queues a message to SupplierMgr 

Encina® Server requesting OnRequestMeterReadings 
service, 

9. SupplierMgr determines the correct Supplier Outgoing 
Encina® Server to message for the meter. 

40 10. RCS Encina® Server (running on NT) checks Local 
database for appropriate reading data. If the data is 
stale, the meter is dialed and the data is read from the 
meter. The readings file is written to the DSF directory. 

11. DispalcherBrain queues a message to the Receiving- 
Mgr Encina® Server requesting ReceiveMeterRead- 
ings service. 

12. ReceivingMgr retrieves the specified readings file 
from DFS and parses the file. The SampleData 
Encina® Server stores the readings in the AMR data- 
base. 

13. DispalcherBrain queues a message to ReadingMgr 
requesting GetMeterReadings service. 

14. ReadingMgr uses MeterSample and SampleData 
5S proxies (MeterSample Encina® Server) to read 

samples from the AMR database. The samples are 
stored in a file in a DFS directory. 

15. DispalcherBrain commits the workflow and notifies 
the DispatcherPanel and ConcemMgr of workflow 

60 completion and final status. 

16. ConcemMgr notifies UtilityMgr of workflow comple- 
tion and final status. 

17. UtilityAgent notifies ConfigUtility of workflow 
completion, final status, and reading file. 

65 18. ConfigUtility notifies the AMR Java™ application of 
workflow completion and readings file. The results are 
displayed to the user. 



45 



50 



04/16/2004, EAST Version: 1.4.1 



US 6,199,068 Bl 



63 



64 



Another facet of the AMR Server 15 is the ability to 
customize the system. Customization is essential because 
the scope of operation for the AMR Server 15 may include 
data collection from meters 60 in different states in the 
United States and world and under varying regulatory 5 
authorities- The system accommodates the application of 
processes such as editing and estimation with unique sets of 
finite rules depending on the applicable regulatory or busi- 
ness practice authority. Examples of parameters that may 
vary include Regulatory Authority Parameters (e.g., state JQ 
agencies, VEE, and Time Synchronization), Utility Param- 
eters (e.g., Meter data freshness values, and Timing and 
quantity of meter reads/retries), and System Parameters 
(e.g., C&I Server system specifications, Standard meter 
characteristics and abilities, Standard communications 
characteristics, Size and duration of data storage, and Size 15 
and duration of system logs). 

The AMR Server 15 will also need to be managed by an 
appropriate set of tools, and accordingly, the AMR Server 15 
Management comprises a basic system management plan 
and tools. The plans are tailored to support existing customer 20 
practices and will include at a minimum, hardware and 
software configuration, management tools, operation docu- 
mentation and operator training. Tools for system manage- 
ment will coincide with existing customer standards. In the 
event no standards exist, platform-specific system manage- is 
ment tools may be utilized to monitor and assist in the 
operation and maintenance of the AMR Server 15. Planned 
maintenance windows for each customer should be 
implemented, and these will be dependent on the customer's 
critical operating time frames. Routine maintenance will be 30 
required and will be staged to provide the lowest impact to 
system operation. 

The tools include a disk storage solution which is con- 
figured to support online and archival storage. Solutions will 
support a variety of options to support growth and scalability 35 
of the system and provide options for hardware and 
software- based raid systems. A backup solution that sup- 
ports both a UNIX and Windows NT® environment should 
be included as part of a "unkey" solution. Backups will be 
sized and automated to provide capacity for growth. Backup 40 
solutions do not require system shutdown since online (i.e., 
live) backups of the Oracles database will be an integral part 
of the backup solution. Data recovery metrics in the event of 
a failure will coincide with defined operational metrics. 

Network Management is preferably provided by the 45 
industry standard mechanism for providing network man- 
agement support, i.e., the Simple Network Management 
Protocol (SNMP). The Oracle® database supports SNMP 
and provides the ability to Monitor the status of Oracle® 
services, Identify performance bottlenecks, "Discover" 50 
Oracle® databases or tools as they start up on any system 
node, Receive alerts when exceptional events occur (i.e. 
database going down), Define thresholds and automatic 
responses to specific events, Detect and diagnose potential 
problems quickly and easily, be notified when certain events 55 
occur, and Store, report upon, filter and analyze historical 
data. 

It is also possible that the Encina® utilities can be utilized 
for the network management of the AMR Server 15 Appli- 
cations. The Encina® utilities provide the ability to: Monitor 60 
error messages, Enable selective tracing of execution path 
events, Dump information about the state of Encina® serv- 
ers (which includes all AMR Server 15s), Analyze queue 
usage, Detect hung transactions, and Monitor server stops 
and starts. 65 

The above-mentioned Oracje®, AMR Server Logging, 
and Encina® network management tools will assist in man- 



aging and isolating system bottlenecks and trouble areas. 
These tools ensure that the entire system remains fictional 
and that no one component causes unscheduled system 
down time. 

It is noted that the foregoing examples have been pro- 
vided merely for the purpose of explanation and are in no 
way to be construed as limiting of the present invention. 
While the invention has been described with reference to 
preferred embodiments, it is understood that the words 
which have been used herein are words of description and 
illustration, rather than words of limitations. Further, 
although the invention has been described herein with 
reference to particular means, materials and embodiments, 
the invention is not intended to be limited to the particulars 
disclosed herein; rather, the invention extends to all func- 
tionally equivalent structures, methods and uses, such as are 
within the scope of the appended claims. Those skilled in the 
art, having the benefit of the teachings of this specification, 
may effect numerous modifications thereto and changes may 
be made without departing from the scope and spirit of the 
invention in its aspects. 

What is claimed is: 

1. In a computer system, a canonical mapper to translate 
an input file from an input domain to an output domain, said 
canonical mapper comprising: 

a canons utility which builds a canon, said canon being a 
tree relating all data attributes within a domain of 
information, and said domain being a collection of data 
that has a same data format; 

a maps utility which creates input and output maps that 
specify the translation from said input domain to said 
output domain, said input map being a data structure 
that describes a format of said input domain, and said 
output map being a data structure that describes a 
formal of said output domain; and 

a translator utility which performs the translation of said 
input file to an output file in accordance with said canon 
and aid input and output maps, 

wherein said input domain and said output domain have 
differing formats. 

2. The canonical mapper as recited in claim 1, wherein 
said canonical mapper converts files over at least two 
mapped subdomains, said at least two mapped subdomains 
having the same root domain. 

3. The canonical mapper as recited in claim 1, wherein 
said input map and said output map are derivation trees, and 
said canonical mapper utilizes said input map and said 
output map to build a scanner/parser for said input file 
domain. 

4. The canonical mapper as recited in claim 3, wherein 
said canonical mapper traverses said input map to parse data 
from said input file into a canonical list. 

5. The canonical mapper as recited in claim 4, wherein 
said canonical mapper maps from said canonical list to said 
output domain to generate said output file by traversing said 
output map and re -interpreting a corresponding element in 
said canonical list such that said corresponding element 
conforms to said output domain. 

6. The canonical mapper as recited in claim 1, wherein 
said canon comprises an abstract template that describes a 
structure of said domain of information, said canon being 
structured as a tree comprising canonical elements that are 
used to interpret data contained within said input file. 

7. The canonical mapper as recited in claim 6, wherein 
each canonical element is an abstraction, and canonical 
elements nested below higher level canonical elements is 
subsequently defined in terms of less abstract elements until 
resolving to a concrete element. 
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8. The canonical mapper as recited in claim 7, wherein 
relationships exist when said domain contains data that is 
dependent upon other data in said domain. 

9. The canonical mapper as recited in claim 6, wherein 
said canonical elements are assigned attributes that define 5 
qualities of said canonical elements. 

10. The canonical mapper as recited in claim 6, wherein 
said input map and said output map are created in accor- 
dance with said canon, and wherein said input map and said 
output map describe the intended output in terms of said 10 
canonical elements. 

11. The canonical mapper as recited in claim 10, wherein 
said input map defines a function of each component of said 
input file in terras of said canon, and said output map defines 

a function of each component of said output file in terms of 15 
said canon. 

12. The canonical mapper as recited in claim 11, wherein 
said input and output maps farther comprise attributes that 
define said canonical elements, tokens that represent values, 
and actions that define the format said canonical elements. 20 

13. The canonical mapper as recited in claim 12, wherein 
said attributes comprise element types and modifiers, 

wherein said element types include group elements that 
are canonical elements that have nested canonical ele- 
ments and result elements contain a specific value, and 25 

wherein said modifiers are associated with said group 
elements and are conditional statements about said 
group element. 

14. The canonical mapper as recited in claim 13, wherein 
said conditional statements comprise optional, repeating, 30 
group results, and mandatory. 

15. The canonical mapper as recited in claim 13, wherein 
said tokens are defined for said result elements and represent 
said specific value based on said input file. 

16. The canonical mapper as recited in claim 1, further 35 
comprising an interactive translator utility to test the actual 
translation of said input file to be mapped for the translation 
process, said test being performed in accordance with said 
canon, said input map, said output map, and said input file. 

17. The canonical mapper as recited in claim 1, wherein 40 
said translator utility runs in a headless mode. 

18. A method of mapping an input file having an input 
domain to an output file having an output domain using a 
canonical mapper, said canonical mapper comprising a 
canons utility, a maps utility and a translator utility, wherein 45 
a domain is a collection of data having a same format, said 
method comprising: 

creating a canon using said canons utility, said canon 

comprising canonical elements; ^ 
creating input and output maps using said maps utility in 

accordance with said anon to perform the conversion of 

said input file to said output file; and 
mapping the information from said input map to said 

output map to create said output file using said trans- 55 

lator utility. 

19. The method as recited in claim 18, wherein said 
creating a canon comprises; 

defining said canonical elements such that said canonical 
elements have a hierarchical structure, said hierarchical 60 
structure having a root and children nested under said 
root; 

defining children of said root, said children defining 

specific information about said root; and 
defining relationships of said canonical elements. 65 

20. The method as recited in claim 18, wherein said 
creating input and output maps comprises: 
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selecting each component of said input file and defining 

its function in terms of said canon; 
defining attributes about said canonical elements; 
defining tokens, said tokens specifying a format of the 

results of mapping said input file using said input and 

output maps; and 
defining actions to structure the appearance of portions of 

said input file or said output file. 

21. The method as recited in claim 20, wherein said 
defining attributes about said canonical elements comprises: 

defining modifiers for said canonical elements, said modi- 
fiers determining if a value of a particular canonical 
element is required, if said value appears more than 
once, if said canonical element includes a series of said 
values, or if said canonical element is required; and 

defining identifiers, said identifiers being constant values 
within said input file. 

22. The method as recited in claim 18, wherein said 
mapping the information from said input map to said output 
map to create said output file further comprises testing the 
conversion. 

23. In a server residing within a multi-layered distributed 
software architecture that receives and processes data, said 
server comprising a data repository to store said data, at least 
one external interface to communicate with systems external 
of said server, a services subsystem comprising distributed 
services, said distributed services running on application 
servers within said distributed architecture, middleware soft- 
ware to facilitate scalability, transaction processing, and 
mapping of objects to said data repository, and application 
frameworks to facilitate access to said data repository and 
the creation of processes compliant with said middleware 
software, a canonical mapper server comprising: 

a canons utility which builds a canon, said canon being a 
tree relating all data attributes within a domain of 
information, and said domain being a collection of data 
that has a same data format; 

a maps utility which creates input and output maps that 
specify the translation from said input domain to said 
output domain, said input map being a data structure 
that describes a format of said input domain, and said 
output map being a data structure that describes a 
format of said output domain; and 

a translator utility to perform the translation of said input 
file to an output file, 

wherein said input domain and said output domain have 
differing formats. 

24. The server as recited in claim 23, wherein said 
canonical mapper server resides in a mapping subsystem 
which provides for customization of file formats for export- 
ing data from and importing data to said server. 

25. The server as recited in claim 24, further comprising 
a mapping interface server that interfaces with said canoni- 
cal mapper, wherein said mapping interface server provides 
middleware service requests from said services subsystems. 

26. The server as recited in claim 25, wherein said 
mapping interface server interfaces with the canonical map- 
per server using a socket connection, and wherein said 
mapping interface server provides a service that allows a 
service in said services subsystem to specify said input file, 
said input map, said output file, and said output map. 

27. The server as recited in claim 23, wherein said input 
map and said output map are created in accordance with said 
canon. 

* + * * * 
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